Re: [Opensync-devel] Ubuntu UDS-Boston, Syncing solutions

On Fri, 2007-11-02 at 02:19 -0400, Martin Owens wrote: 
> Hi, I'm not quoting as the topic is quite large so I'm making points
> and then commenting:
> 1) Mobile Phone functionality - We shouldn't be worried with or
> including none syncing functionality in plugins for syncing (this is
> just confirming) if a phone can act as a modem or a network device
> that's great but let some other HAL callback handle that.
The plugins for syncing won't include such functions. You are right. A
sync plugin should just sync. However, in enabling usb-rndis-lite you
are also allowing windows phones to be used as an internet gateway. So
you need to be aware of that and consider what to do - remove the part
of the patch that allows this (boo!) or make sure that it doesnt break
anything (in this case, the default of NetworkManager auto-configuring
it is probably the ideal case anyway so its a moot point).

Also, making effort *not* to ship supporting utilities (for example,
SynCE has some kind of "VNC for phones" type feature) would be
unfortunate... Especially when they are packaged and "just work" as a
result of the other integration efforts.

(I am keen to distance myself from the notion of shipping them by
default though).

> 2) In HAL fdi functionality we should be idenfiying things as
> 'sync_point' or 'pim' not as 'mobile_phone' since Palm, WinCE, iPods
> aren't phones (and ipods arn't even pims but we need to sync music,
> photos and other things too)

> 3) All hardware talking to the computer should have HAL device nodes,
> the callback code which is a fantastic idea needs to call the required
> query code and add required information back to HAL; this includes a
> unique identifying string of some kind, a space for refined model
> (where more than one phone has the same usb device id) and a list of
> capabilities that the sync plugin needs to do the right thing.
Right. So a new WM device is plugged in. The eth* is dhcp'd and hal 
callout probes for more information - passing it back in to HAL property 
nodes. In theory this even allows for device-specific icons... 

Capabilities i'm not as sure about, especially as some devices need to 
actually sync to establish that information...

> 4) The callback code can actually add functions to HAL, not just data.
> so we can create a set of sync information and a sync end point code
> hook which opensync could _very_ easily take advantage of to talk to
> hardware without having to store so much.
Don't understand. What is the advantage of this? Knowing which plugin 
to use should be enough? And remember that opensync has no desire to 
depend on HAL.

> 5) OpenSync must be able to sync on the fly without requiring
> configuration files; at the moment opensync's config requirements
> holds it back from integration directly and offering the functionality
> via dbus to tie a hardware node to another software data plugin is the
> best option to allow us to create front ends that don't need to mess
> about so much with config files (besides most of this config is going
> to come from HAL and the information callbacks)
Right. You can configure it via the API though. Conduit will take care 
of configuring much of this stuff. If it needs to come from the user or HAL, 
we will pass it in correctly. If its something that can be put in 
opensync (without HAL deps) we will.

> 6) Where opensync does have configs they should be set up per end
> point, not under a list of sync end points as is currently the case.
> this would enable more than one phone to sync with kdepim without the
> same kdepim config being duplicated.
Could you elaborate on this point, i dont follow your meaning.

> I've still yet to qrite up the notes from the meeting, my laptop is
> suffering heat problems and it's not in a good state (it only has half
> a gutsy install and the machine dies of overheating before the install
> can finish) so anyway I will get my friend to grab the gobby text and
> I'll run through it all.
Unlucky :( My other laptop ocasionally needs its fans cleaning because of 
overheating. Generally there is 1cm of fluff wedged between the fan and 
heatsink :( Sucks! Could try powersave governor?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]