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

On Thursday 01 November 2007 21:15:40 Pawel Kot wrote:

(Sorry for double post - attachment would increase the message body size up to 

> > 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.
The capabilities set of fields and the _max_ occur of those fields.

> >
> > 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="" type="string">Nokia 6230i</merge>
>       <merge key="mobile_phone.syncml" type="string">yes</merge>

Isn't USB_CDC_CLASS and USB_CDC_FBUS_SUBCLASS in combination with the vendor 
USB ID of Nokia enough?

/* Nokia is the vendor we are interested in */
#define NOKIA_VENDOR_ID 0x0421

/* CDC class and subclass types */
#define USB_CDC_CLASS                   0x02
#define USB_CDC_FBUS_SUBCLASS           0xfe

I would suggest to write a hal preprobe callout application based on the 
dku2libusb.{c,h} code or something like that which got called if the Vendor 
and the CDC CALL and SUB CLASS matches. And take the data from the 
fbus_usb_interface struct and merge it into the Device FDI entry.

So there is no need to write a hardcoded HAL FDI file.

>       <merge key="mobile_phone.connection" type="strlist">bluetooth</merge>
>       <append key="mobile_phone.connection" type="strlist">irda</append>
Not quite sure if this is needed .. since the device wouldn't appear currently 
in HAL anyway. Bluetooth remote device aren't listed at the moment in HAL, 
same for IrDA - AFAIK. You should only feed HAL with data about currently 
connected devices...

>       <append key="mobile_phone.connection"
> type="strlist">usb_dku2</append> <merge key="mobile_phone.driver"
> type="strlist">AT</merge>

This should be already available in HAL. HAL provides all information about 
the USB Interfaces and their sub classes. Example - Nokia 6230:

dani noname:~> lsusb -s067
Bus 001 Device 067: ID 0421:040f Nokia Mobile Phones 6230 GSM Phone

If you run lshal ( ) 
you'll find something like:

  usb.interface.class = 2  (0x2)  (int)
  usb.interface.number = 1  (0x1)  (int)
  usb.interface.protocol = 1  (0x1)  (int)
  usb.interface.subclass = 2  (0x2)  (int)
Subclass 0x2: AT Protocol (PCCA101)

  usb.interface.class = 2  (0x2)  (int)
  usb.interface.number = 3  (0x3)  (int)
  usb.interface.protocol = 0  (0x0)  (int)
  usb.interface.subclass = 254  (0xfe)  (int)

Subclaass 0xfe: Likely a FBUS Interface if the Vendor is Nokia ;)

So this data is already available without writing FDI files...

>       <append key="mobile_phone.driver" type="strlist">series40</append>
>       <merge key="" type="string">Nokia 6230i</merge>
Couldn't we just probe for Name and other information?
Most device get in meanwhile correctly announced:

  usb_device.product = '6230 GSM Phone'  (string)
  usb_device.vendor = 'Nokia Mobile Phones'  (string)

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

We could write a preprobe callout which request x-obex/capabilities.
Try "obexftp -u 0 -X" this is requesting x-obex/capabilities.
Example from my Nokia 6230:

This would be nice to get those information merged into 
HAL while the mobile get connected - without hardcoding it to a FDI file.

> > 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.
I thought about something for libsyncml, so it's not only limited to the 
platforms which running HAL. So libsyncml could be used with the correct 
identifiers also on Macosx and Windows.

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

I meant more general the fields which got described in vObject, not the format 
itself. Most mobiles still use vCard 2.1 .. so far i only saw some few newer 
Sony Ericsson mobiles which stores vCard 3.0 as well (but have vCard 2.1 as 
fallback). I guess thats the reason why they started to write a draft for 
vObject (the initial draft is from October 2007!).
> > > > 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.

Not really in the case of SyncML - example:

> 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.
I'm not that familiar with FBUS, but with x-obex/capabilties it's possible -

Do you have some specs/references or whatever about FBUS?
Maybe we could improve the FBUS protocol implementation and allow to detect 
which format is used on the other end...

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

We have some facilities in OpenSync to workaround that... just write a 
capabilties.xml for the device and place a description.xml (like in the 
previous mail). So it skips the devinf from the device.. since the 
capabilities files have _always_ higher priority then the device requested 

> Why minimum? We want maximum! 
Oops, correct.

> 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.
D-Bus is just the IPC used by HAL ... it doesn't play any further role in this 
game. OpenSync doesn't have the exceptions database, only the plugins. And 
the plugins only needed manually generated capabilities files if the protocol 
implementation which is the plugin based on doesn't provide this information.

With protocol implementation i mean for example: libsyncml, gnokii, synce 
(librapi), libpisock (pilot-link), IrMC (plain libopenobex), ...

HAL could make use of them, with little callout application for example, which 
do the discovery of the capabilities, or some necessary probing to identify 
the device. And then merge those information into the device fdi .. so the 
appear in the HAL FDI tree - during runtime!

I think about having this callout application:

Request just x-obex/capabilities and merge it into the obex interface fdi of 
HAL. That's enough to identify that SyncML or IrMC is available. The 
capabilities discovery for each objtype could be done easily with application 
which are based on libsyncml and openobex (for IrMC). In case of OpenSync 
this is planned for the IrMC and SyncML plugin... I'm not aware of any other 
used IrMC and SyncML implementation whihc makes use of OpenOBEX and libsyncml 
so far...

If the obex_callout probe results something it should merge
sync.protocol = [ "syncml-obex", "irmc" ]
sync.syncml.version = [ "1.0", "1.1", "1.2" ]
sync.syncml.format = [ "wbxml", "xml" ]

Make use of libusb transport code from libpisock to probe if the USB Interface 
is an active HotSync interface. And merge something like this:

sync.protocol = [ "palm-hotsync" ]

Capabilities shouldn't be needed since there are only two different formats 
for contacts and events. Addressbook(old), ContactDB(new) and Datebook(old), 
Calendar(new) .. or something like that. First check if one of the newer 
databases exists, fallback if they don't exist ... capabilities are fixed for 
old and new databases.

Use the dku2libusb and check if the usb interface fits.

sync.protocol = [ "fbus" ]

But in this case your might be right... since you can't get any data from you 
might need to hardcode most capabilities. But the big advantage is if you 
stay with your "capabilities" with in "misc/common.h" it's independent of 
HAL. You could use those information from "misc/common.h" during the probe 
from the fbus_callout and merge them into HAL. So gnome-phone-manager, 
kontact and gnokii-sync and other libgnokii based application could benefit 
from that.

> > 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
Same if you would write it into as plain FDI file an place same 
into /usr/share/fdi/...

>  - it isn't really maintained
Could be the same for HAL FDI files ;)
And it's not portable to non-HAL platforms.

> > > 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"?
I meant that someone changes the IMEI and break that the device can't be 
identified by his Sync setup or something like that..

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