CTDB API

Volker Lendecke Volker.Lendecke at SerNet.DE
Wed Nov 1 07:20:19 GMT 2006


On Wed, Nov 01, 2006 at 10:02:35AM +0300, Alexander Bokovoy wrote:
> Exactly. THis is layed out in last sentence of my previous mail:
> We thought that probably it makes sense to split dispatcher code as CTDB
> layer (tdb, protocol, events, main()) and application-specific part
> (Samba-specific code in this case) so that actual dispatcher daemon
> would be produced by combining otherwise common CTDB 'library' and
> application-specific hooks (conditions, triggers, parsers).
> 
> The key thing here that if we could abstract conditionals/triggers so
> that they deal only with data in databases and all actual CIFS-specific
> reactions would be in client code (smbd), it would not impose much
> dependency fixing.

I think in this stage anything is fine, I think a first
implementation of the base protocols is more important. I
think the fine details of negotiating the exact conditional
and/or implementation needs to be fixed before we go
production, but for now _I_ would not put too much emphasis
on this point. I would implement a string-based argument to
the open call or a separate call which tells the daemon
which semantics we're talking about and implement it in the
server. Certainly this needs to be modularized, but I would
go for a quick and dirty one first, because I think we can
not _really_ cleanly solve this, essentially this
corresponds to sql stored procedures. Executable code
embedded in the database on different architectures....

Just my 2 cents :-)

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20061101/7f97bff7/attachment.bin


More information about the samba-technical mailing list