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

[Daniel Gollub <dgollub suse de>]

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?

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

Which is a generated fdi file from libgphoto2.
Example entries:

   <match key="usb.vendor_id" int="1276">
    <match key="usb.product_id" int="20555">
     <merge key="info.category" type="string">camera</merge>
     <append key="info.capabilities" type="strlist">camera</append>
     <merge key="camera.access_method" type="string">proprietary</merge>
     <merge key="camera.libgphoto2.name" type="string">Aiptek Smart 
Megacam</merge>
     <merge key="camera.libgphoto2.support" type="bool">true</merge>
    </match>
   </match>
   <match key="usb.vendor_id" int="1452">
    <match key="usb.product_id" int="4752">
     <merge key="info.category" type="string">camera</merge>
     <append key="info.capabilities" type="strlist">camera</append>
     <merge key="camera.access_method" type="string">ptp</merge>
     <merge key="camera.libgphoto2.name" type="string">Apple iPhone (PTP 
mode)</merge>
     <merge key="camera.libgphoto2.support" type="bool">true</merge>
    </match>



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

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

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


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

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.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<versions version="0.1">
        <version>
                <PlugIn>gnokii-sync</PlugIn>
                <Priority>100</Priority>
                <Vendor></Vendor>
                <ModelVersion>6310i</ModelVersion>
                <FirmwareVersion></FirmwareVersion>
                <SoftwareVersion></SoftwareVersion>
                <HardwareVersion></HardwareVersion>
                <Identifier>gnokii-6310i.xml</Identifier>
        </version>
        <version>
                <PlugIn>gnokii-sync</PlugIn>
                <Priority>100</Priority>
                <Vendor></Vendor>
                <ModelVersion></ModelVersion>
                <FirmwareVersion></FirmwareVersion>
                <SoftwareVersion></SoftwareVersion>
                <HardwareVersion></HardwareVersion>
                <Identifier>gnokii-minimumset.xml</Identifier>
        </version>
</versions>

gnokii-6310i.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<capabilities>
        <contact>
                <AddressLabel />
                <Categories />
                <EMail />
                <FormattedName />
                <Telephone />
                <Url />
       </contact>
</capabilities>


gnokii-minimumset.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<capabilities>
        <contact>
                <AddressLabel />
                <Categories />
                <FormattedName />
                <Telephone />
       </contact>
</capabilities>

If i know package those capabilties files into gnokii-sync and configure 
gnokii-sync with <model>6600</model> it will fallback to the capabilities 
explained in gnokii-minimumset.xml. If would set <model> to 6310i it would 
fist match gnokii-6310i.xml

>
> > > > 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,
I know :(

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