On Fri, 2009-10-16 at 10:15 +0200, Guido Diepen wrote: > Hi Mark, > > > Hi Guys (John, copied you in in case your working on anything > > significant). > > > > I've been meaning to do a few things to sync engine, and I've finally > > got around to figuring out how I want some of it to work. This is a > > request for comments, ideas, help with some sticking points, and sanity > > checking :) > > > > It started with wanting to get pre WM5 devices into sync engine, at > > which point I decided this would be easier if sync engine was designed > > to handle multiple devices, because then you just support 2 classes of > > device. Of course multiple devices would be cool anyway, so I'll do that > > first. > > I do like the idea of just having one sync-engine that can handle both the > post wm5 devices, as well as the pre wm5 devices. Regarding the multiple > devices, I still have not gotten around to test this, but does it actually > work in Windows to have multiple WM5/6 devices connected at the same time? > >
Fundamentally this is a good idea. I basically started to re-work the syncdb component of sync-engine prior to integrating it with the functioning components of librra to allow pre-WM5 devices - then the only WM2002 device I have for testing decided to stop working, so I couldn't test it (problem with the HAL component of synce). This was some time ago, things have moved on so will try again to get the WM2002 device connected and see if it works this time! > > > > > > The first bit is quite easy, move a lot of stuff from the SyncEngine > > class into a new Device class, and have SyncEngine maintain a collection > > of Devices. I intend to then have an 'active' device which all sync > > activities act on. This is not complete multi device functionality, but > > would allow multiple devices to connect without confusing sync engine, > > which I believe would cause problems at the moment. > > I have to say that this idea sounds pretty sane to me. > > > > > > > > The next step I haven't completely ironed out yet, but would be > > something like this. > > > > Each Device would advertise the dbus interface on its own object path, > > either using the device id or partnership id as part of the path, I'm > > not sure which. The opensync sync group would then have device and > > partnership info as part of its config, so it could contact the correct > > dbus object. This would also tie an opensync group to a partnership, > > which is definitely a good thing. > > Indeed the last part is indeed a good thing. It would also allow for > aborting cleanly in case you are using a different device with the > opensync group, instead of messing up everything. > > > > > > I've currently got two problems with this second part. Firstly, creating > > a partnership and sync group would have to be combined for everyday > > users, and I can't decide the best way to do that. > Multiple devices would be an ideal - it should not be too difficult to map a partnership to a specific device. The internal syncdb is encapsulated and this should not be at all difficult on the SynCE/sync-engine side. The problem would be on the opensync side- enforcing the mapping between an opensync group and a sync-engine internal syncdb. > One possibility would be creating a partnership name in the opensync > configuration for our synce plugin. You could then see if it is possible > to have the opensync-synce plugin talk to sync-engine, see if the > partnership exists. If it does not exist AND if there is a free slot, the > partnership with the given name will be created automatically. > I like this approach - it would make sensible use of the opensync configuration mechanism and would enforce Opensync group bindings to both a specific device and a specific partnership. The current per-partnership XML configuration could be placed in the Opensync plugin configuration - this would suit Opensync 0.4x well. We would need a mechanism to delete dangling partnerships on the sync-engine side if they have been deleted by connection of the phone to another host - otherwise they will get recreated when the phone is next plugged in. > > Using the above would enable users to only have to set the partnership > name in the configuration for opensync, and the partnership would be > created automagically. > > Let me know what you think about the above approach. > Would work well, I think. And enable us to eliminate the command-line partnership creation. John. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
