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

[Daniel Gollub <dgollub suse de>]

On Thursday 01 November 2007 16:37:44 Michal Čihař wrote:
> Dne Thu, 1 Nov 2007 14:10:06 +0100
>
> Daniel Gollub <dgollub suse de> napsal(a):
> > As i already mentioned, I'm not a friend of hardware databases -
> > especially if it's possible to detect the interface/service/protocoll in
> > a certain way. Not quite sure if you know how complex the capabilities
> > (fieldtype, number of fields, ...) of certain devices is...
>
> About the fields there is sometimes only reliable way to try to write
> it. Eg. over IrMC, phones can somehow export what they support,
> but you can not tell from that how many phone numbers you can store on
> them. The other thing which you usually can not find out until actually
> trying to write and item is maximal length of fields.
>
> I also do not like idea of hardware database, but I also do not think
> that trying to write to every device just to find out capabilities is a
> good solution.
>
> > I only know a few protocols which are intended as synchronization and
> > don't provide capabilities information. The few protocols which aren't
> > intended to be a synchronization protocol but used to do syncing, mostly
> > have fix set of capabilities. Best example for that is gnokii. You should
> > ask Pawel Kot about that ;)
>
> Well I do Gammu (fork of Gnokii long time ago), so I pretty good know
> the situation here. You have fixed set of capabilities per protocol, but
> each phone actually supports some subset of this. Look at Nokia phones,
> they always add new fields to new models so you add them to protocol,
> but the old phones will reject them.

What about older (Nokia) mobiles which didn't support IrMC and SyncML?
Do they have a fix set of capabilities?

I'm speaking now just about syncing (not the phone manager tools which using 
gammu and gnokii), but i would recommend to just use by default the minimum 
set of known capabilities for the older phones. Since if the mobile supports 
SyncML it should be used to do syncing. The next would be IrMC and then 
gnokii/gammu... but this wouldn't bring any benefit for gnokii or gammu. I'm 
aware of the Phone-utopia project. Maybe there you should build some common 
base for capabilities for older (and maybe newer) mobiles.

Maybe the OMA vObject Minimum Interoperability Profile fits even the 
capabilities set of older mobiles and would be a good base to start with:

http://www.openmobilealliance.org/release_program/vObject_v1_0.html

At least i plan to fit the needs of vObject with the OpenSync vformat 
plugin...

What about unifying efforts in phone-utopia to collect such basic 
capabilities. It would also interesting to get there a basic set of AT+ 
commands...

I would suggest to make this set of capabilities independent of HAL, since 
it's just fixed data. This would allow other application and OpenSync to 
fallback to get information like which fields are support and (what isn't 
often provided even not always by SyncML) what is the max occur of this 
field.

OpenSync 0.3x has an own implementation to provide fixed capabilities. But we 
intend to make only use of fixed capabilities if it's really needed. For 
example if the firmware of the mobile is buggy, and can't store the ZIP code 
of the 3rd Address (like my Palm T|X) - so we overwrite the reported 
capability set of the device with a fixed set of capabilities which 
workaround this bug. But this is only in rare cases.

Currently for gnokii-sync we would need to write a minimum set of capabilities 
which are supported by all mobiles. And write further capabilities for 
mobiles which are known to support more fields... but if gnokii/gammu or even 
phone-utopia could provide this own data would be only a fallback solution.

>
> > This actually should be only the synchronization protocoll... more isn't
> > needed. At least the frontends of OpenSync doesn't need more
> > then: "syncml-via-obex", "irmc", "palm-hotsync", ...
> > So they can choose the right plugin, trigger the discovery process of the
> > plugin and get all the capabilities information ... in a protocoll
> > specific way.
> >
> > Unique ID sounds intersting ... should this be done by a callout process?
> > What do you want to use as Unique ID? IMEI?
>
> For bluetooth you can use MAC address, not sure about others.
Yes, bluetooth is easy .. but currently the BlueZ integration in HAL is 
missing. Regarding the meeting minutes of the last BlueZ developer meeting 
HAL integration will be done with BlueZ 5.0

http://wiki.bluez.org/wiki/Meeting-2007-09-12

So for now i recommend to listen to HAL and BlueZ D-Bus signals ...
I see more the problem about a unique ID for devices connected via USB. Two 
mobiles, connected via USB, same models, two different users, same system - 
usecase: laptop pool. (It's not about multiseat, but could be as well, it's 
more about different sessions for now ...)

Often the vendor software probes for the IMEI with AT+ commands.
(Not quite sure how the IMEI should be handled, since it's kind of sensitive, 
isn't it?)

AFAIK, without triggering a sync this is the only way to identify the mobile.