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

["Pawel Kot" <gnokii gmail com>]

Hi,

On 11/1/07, Daniel Gollub <dgollub suse de> wrote:
> 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):
> > > 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?

Well, not really. There are some phone series that do have the same
capabilities. Few years ago there were just few phones available.
These days we have hundreds of phones and they differ a lot between
themselves.

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

My understanding of HAL is that despite of plug/unplug information it
has also some kind of the hardware database. IMHO creating another
database is not the right way to go. I know that not many applications
will use it. But certainly "our" database will need to duplicate HAL
information.

By the way, in the Windows-Nokia world it has the worst solution I
could imagine. The capabilities are hardcoded into the application.
Sequent capabilities are added in the sequent PC Suite releases. And
if you have older phone you cannot use new PC Suite version (there's a
wizzard on their website telling you which app version you need to
download).

> 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

I am afraid that is not enough. The problem is that if you want to
store some vcard and a phone doesn't support some field you want to
store, it won't tell you that. It will reject the frame (when talking
about FBUS protocol). Fortunately you can group phones into certain
cababilities model. I already have designed some simple relation group
model, but I belive that having separate database for the phone
managers is the wrong architectural decision.

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

I will provide a model I have on phone-utopia wiki (I think I'll move
my gnokii devel branch work into p-u) but still, I am convinced that
it will duplicate partailly something already exists.

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

But first you need to know, if the device supports ZIP code at all, right?

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

I don't think I follow this logic. Could you explain in more detail?

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

IrDA is problem as well,

> 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?)

It is. Additionally it can be changed (although it is illegal in some
countries). On the other hand Nokia PC Suite uses IMEI as a phone
identifier.

take care,
pkot
PS. I'm CCing Daniele, who may also be interested in this discussion part.
-- 
Pawel Kot