Re: 0.90 questions

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