Re: [Opensync-devel] Ubuntu UDS-Boston, Syncing solutions
- From: "John Stowers" <john stowers lists gmail com>
- To: "Daniel Gollub" <dgollub suse de>
- Cc: Conduit <conduit-list gnome org>, opensync-devel lists sourceforge net
- Subject: Re: [Opensync-devel] Ubuntu UDS-Boston, Syncing solutions
- Date: Thu, 1 Nov 2007 08:39:32 +1300
>
> > --> I have thought long and hard about making the command line
> > tools syncml-obex-client and syncml-obex-server into dbus daemons .
>
> I fully disagree ;)
> There is something called HAL...
> It's just about x-obex/capabilties - you should have a look at the OBEX spec.
see below
>
> > The FDIs in this case could also encode the quirks and specific syncml
> > config attributes for the phone, if connected over USB (see the
> > opensuse wiki for a list of these).
>
> I heard of quirks and i really don't like quirks. Especially i don't like
> quirks if it's possible to avoid quirks if the device protocoll fits all your
> needs ...
>
> > At this point I would (1)
> > communicate with the daemon from conduit over DBus. I would also (2)
> > rewrite the opensync syncml plugin(s) to communicate with these
> > daemons over dbus. Obviously I have not yet considered how much work
> > (2) is, and even if its possible. While this still has some code
> > duplication, its at least an effective middle ground (through
> > libsyncml). I would appreciate your thoughts on this.
> Sorry, this is really not needed. You should have a look on the OBEX Spec.
> The commandline tool obexftp has a simple reference implementation how to
> request the x-obex/capabilties. "obexftp -X"
>
> If the HAL developers don't fully disagree with my idea of implementation
> there is no need to have yet another system daemon.
See below
>
> But i see your point in have same process/daemon running which takes care all
> the time about triggering a sync or reporting there is a new and unknown
> device which could be synced.
>
> I already had an idea about a (D-Bus) session daemon (which is desktop
> independent), which could handle mobile devices related stuff. Like
> triggering a sync if your local PIM environment added a new bunch of new
> contact entries... so periodic sync like every 5 Minutes is not needed. I
> would suggested to only do syncs if the device appear and is after 5 Minutes
> still available. I called this "MobileStation" - anyway thats quite offtopic
> now ;)
I actually think we are in some sort of agreement.
I did not suggest that the syncml-obex-client should run all the time,
being yet another system daemon. My point was that putting all of the
policy regarding device sync into a daemon is (IMHO) a good idea. The
daemon+callout+HAL could manage almost everything. We could even
autostart said daemon if/when bluez detects/pairs with a nearby mobile
phone
As John suggested a hal callout that queries the obex capabilities of
the device could then start the appropriate daemon in response to the
device cabilbities sounds interesting.
Regards,
John
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]