On Mon, 2004-03-15 at 18:01, Tom Foottit wrote: > On Mon, 2004-03-15 at 10:45, Armin Bauer wrote: > <snip> > > the dbus offers a much greater independence to the plugins since they > > can interecept and alter all the communication between the engine and > > the plugin. > > > > so here is my proposal: > > - dlopen the plugin > > - call a function on the plugin which installs a message handler which > > sees all the messages of a certain format > > - provide convinience functions to these plugins for say extracting the > > SyncObject from a message etc > > > > this way we dont need a new process but still get the flexibility of > > using it with the bus > > This sounds good to me. > > > > what i meant is if we should allow every plugin to use its own config > > format or if we should require every plugin to use xml. > > Understood. > > > > > storing a config would look like this: > > > > - client calls storeconfig(pointertoconfig) > > - we base64 encode the config as it is > > - transmit it over the wire via dbus > > - multisyncd process stores it away > > Ok. > > > > > currently if have the config file for a syncgroup like this: > > > > <syncgroup> > > <member> > > <type>palm-sync</type> > > <uid>122134</uid> > > <config> > > <username>Armin Bauer</username> > > <id>1000</id> > > <debuglevel>1</debuglevel> > > <type>0</type> > > <speed>115200</speed> > > <timeout>0</timeout> > > <sockaddr>/dev/ttyS1</sockaddr> > > <popup>1</popup> > > <mismatch>1</mismatch> > > </config> > > </member> > > <member> > > <type>ldap-sync</type> > > <uid>123234</uid> > > <config> > > <servername>localhost</servername> > > <serverport>389</serverport> > > <binddn>cn=admin,dc=debian,dc=org</binddn> > > <pwd>test</pwd> > > <searchbase>ou=people,dc=debian,dc=org</searchbase> > > <filter>(cn=*)</filter> > > <scope>1</scope> > > <debuglevel>1</debuglevel> > > <authmech>SIMPLE</authmech> > > <encryption>0</encryption> > > <write>1</write> > > <anonymous>0</anonymous> > > </config> > > </member> > > </syncgroup> > > This means that the sync engine has to have knowledge of each plugin's > configuration parameters, which is probably a bad idea.
thats the great thing about xml: i can just take the <config> portion of it and manufacture a new file from it. i dont need to know anything what is within the <config> > Why not have the > <config> tag store the base-64 encoded configuration string as an opaque > value? It wouldn't even have to be XML :) thats of course also an option. > > > > > so everything below <config> would get sent to the plugin as xmlcode > > (thats very easy to implement). the other possibility would be: > > > > <syncgroup> > > <member> > > <type>palm-sync</type> > > <uid>122134</uid> > > <config>path/to/configfile1</config> > > </member> > > <member> > > <type>ldap-sync</type> > > <uid>123234</uid> > > <config>path/to/configfile2</config> > > </member> > > </syncgroup> > > > > here the configfile could hold any dataformat choosen by the plugin. if > > needed it will be loaded , base64 encoded and transmitted. > > This would be the other option, but I kind of favor it stored in one > master config file with multisyncd. That way the individual plugins > don't have to implement their own config. i would rather like to see it in one config file too. > > Tom > > > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Multisync-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-devel
