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

["Pawel Kot" <pawel kot+opensync gmail com>]

Hi,

On 11/1/07, Daniel Gollub <dgollub suse de> wrote:
> On Thursday 01 November 2007 17:50:50 Pawel Kot wrote:
> > > 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.
>
> Yeah, but those older phones which doesn't support SyncML nor IrMC should have
> nearly the same minimal set of capabilities - right?

Depends on what level of granularity you define 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.
> >
> > 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.
>
> Check /usr/share/hal/fdi/*
>
> Maybe a interesting example is
> /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi

It fits exactly my needs. I'd like for every device having defined
which group of features does it support. For example:
    <match key="usb.vendor_id" int="0x0421">
     <match key="usb.product_id" int="0x0428">
      <merge key="info.category" type="string">mobile_phone</merge>
      <append key="info.capabilities" type="strlist">mobile_phone</append>
      <merge key="mobile_phone.name" type="string">Nokia 6230i</merge>
      <merge key="mobile_phone.syncml" type="string">yes</merge>
      <merge key="mobile_phone.connection" type="strlist">bluetooth</merge>
      <append key="mobile_phone.connection" type="strlist">irda</append>
      <append key="mobile_phone.connection" type="strlist">usb_dku2</append>
      <merge key="mobile_phone.driver" type="strlist">AT</merge>
      <append key="mobile_phone.driver" type="strlist">series40</append>
      <merge key="mobile_phone.name" type="string">Nokia 6230i</merge>
      <!-- I am not sure at the moment if it would be required -->
      <merge key="mobile_phone.series40.phonebook"
type="string">nokia_extended</merge>
      <!-- vcard21, vcard30, nokia_dct3, nokia_series40,
nokia_series40_3rdEd, symbian, ... -->
      <merge key="mobile_phone.AT.phonebook" type="string">vcard30</merge>
     </match>
    </match>

I think I could work more on this example, but this is kind of
information I need, and HAL db seems to be a perfect match. Although
it again duplicates somehow what is in udev rules. Udev rules describe
the same devices as HAL configuration. And it is easier to add
configuration in one place then in serveral places.

> > 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).
>
> Full agree, i often hit the problem even with Nokia mobiles and SyncML. We
> have to set/fake the identifier string for certain mobiles. On some mobiles
> it is "PC Suite" on other it's "PC Suite Data Sync" - otherwise the mobile
> reject with a "internal server error"....

Yeah. And again, identifier could be a property for the device in HAL db.

> > > 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.
>
> Did you really check vObject spec - is even this minimum set of capabilities
> to complex for older mobiles?

I meant two things. This specification doesn't cover all my needs (ie.
phonebook, calendar are not enough). Old mobiles are not compliant
with VCARD21 (some of them).
But still: you need to know with which vCard specification a phone is
compliant. Where do you get this information from?

> > > 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?
> Correct... but beside FBUS most protocols really have fixed capabilities (like
> Palms only differ in two different - afaik) or you can request them (SyncML,
> IrMC, ...)

Perhaps I don't know what I am taking about, but in this case it is
not SyncML but vCard2.1 or vCard 3.0 which define real capabilities.
So I may prepare for myself some other specifications, like
NokiaPBook1.0, NokiaPBook2.0, .... And that's fine. I just would like
to have someone to tell me: Hey, some device got just connected. It
supports NokiaPBook 2.0 in FBUS mode and vCard 3.0 in obex mode.

> > > 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?
> If you want to sync for example Mobile xyz and the mobile supports: SyncML,
> IrMC and F-BUS. Then it should prefer SyncML - since it can request the
> capabilities. If it would only support IrMC and FBUS, it should prefer IrMC,

If SyncML has an option to ask for capabilities that's great. Just
remember that claiming being compatible with spec, doesn't mean being
compatible. So I still think you will need some database for the
exceptions.

> it also can report capabilities. If the mobile supports only FBUS it should
> try with a known minimum set of capabilities provided by
> gnokii/gammu/phone-utopia.

Why minimum? We want maximum! And look: that way we have the same
device configured for: DBUS (to load a driver, configure device file,
run an app etc), HAL, opensync (exceptions database), phone framework
(capabilities over divverent drivers). That's IMO overengineered.

> Not quite sure if gnokii already provides such fixed capabilities information
> by protocol/model via the libgnokii API. But if not we could write for
> gnokii-sync own capabilities files for certain devices and package them with
> the plugin.

It does (see common/misc.c), but:
 - it is hardocded currently
 - it isn't really maintained

> > > 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.
> But this case shouldn't be supported...

"This case"?

take care,
pkot
-- 
Pawel Kot