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 :) > > 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. > > 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. 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
