On Mon, 2004-03-15 at 16:25, Tom Foottit wrote:
> On Mon, 2004-03-15 at 09:39, Armin Bauer wrote:
> <snip>
> > I started to work on 0.90, especially on the dbus framework we need.
>
> Remember to keep it in your sandbox until we branch 0.82 :)
i currently keep it on my companies CVS
>
> >
> > But i have come across some questions:
> >
> > 1. how to write the syncType plugins (the plugins that handle the
> > formats that are passed through the engine)? .so and load them with
> > dlopen in the engine? .so and let them run in a separate process and
> > connect with the dbus? anything else?
>
> Well, using dbus over a simple dlopen() would require the sync type
> plugins to need the advantages of dbus - namely the independence
> provided by a separate process. Right off the top of my head I can't see
> why they would, so dlopen()ing them should be ok.
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
>
> >
> > 2. the config files for the syncPlugins:
> > the syncplugins still need to be configured (what currently is in the
> > files like "remoteevolution"). Should we just provide two functions for
> > the plugins "loadconfig" and "storeconfig" which will take arbitrary
> > data and pass the config through the dbus and let multisyncd store it?
> > or should we only use xml (would mean that every plugin needs to parse
> > xml configs)?
>
> This is a good question. If each plugin stores its own configuration
> then you get flexibility at the cost of more work for the plugin writer.
> If we store the the configuration centrally then it will be easier to
> write plugins and debugging config problems will be easier. So, I think
> that I would prefer a storeconfig()/loadconfig() approach.
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.
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
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>
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.
>
> 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
