Re: [Opensync-users] Plugin for gnokii

[Armin B. <arm...@de...>]

Matthew Kay wrote:

>Thanks for all your comments and help, Eduardo.
>
>
>  
>
>>Do you know which protocol does gnokii implement, to access your phone?
>>    
>>
>
>It uses a serial protocol to communicate with the phone directly, I
>think. This can be over Bluetooth, Infrared or cable. See
>http://www.gnokii.org/ for more details.
>
>My motivation is that I want to synchronise my Nokia 6670 phone over
>bluetooth. This requires a TCP/IP connection with the phone, though -
>see
>http://multisync.sourceforge.net/wiki/index.php?Nokia6600Instructions
>for a description of the overall process. Setting up a TCP/IP connection
>over bluetooth with modern Nokia Series 60 phones (see 6600, 6620, 7610,
>6670, 6260, 3230, 6630, 6680) requires a bit of messing around with a
>piece of software called Gnubox which you need to install on the phone
>in order to set up a suitable access point (the phone software is
>intentionally crippled so you can't do this, presumably to encourage
>users to use GSM/CDMA internet access rather than connecting to
>something cheaper over bluetooth).
>
>I had no success with this. Apparently people have got it to work. See
>the gnubox website (http://gnubox.dnsalias.org/gnubox/) and fora
>(http://www.symbianos.org/yabbse/index.php?board=2). However, it's a
>messy business since the authors have to make changes for each new phone
>that comes out, and requires you to manually initiate a sync even when
>it does work.
>
>The gnokii approach, on the other hand, is to have a server-client
>architecture. Their Symbian .sis file is called GNAPPLET and can be run
>on any of the Nokia Series 60 phones, for which a consistent API is
>provided (so they update it for new features they've implemented, not
>compatibility with new phones). Recent development means you can simply
>run it in the background on your phone (no timeout) and make remote
>requests to it. Since I rarely turn my phone off, this is perfect for
>me. I can make requests from my laptop like 'gnokii --getphonebook ME 1
>end -v' which gets all contact entries from the phone and dumps them out
>into a VCARD. Without that -v switch, it gives the output I gave earlier
>in the thread. And I can script these for daily backups, for instance. 
>
>  
>
Would it be possible to get the information in your python plugin in a 
vcard as well? Then you would have any problem with formats. You could 
just report the data as a vcard and your done.

>I forget that the server/client business and can interact with my phone
>very naturally without manually initiating anything on the phone side.
>It would be amazing if I could use this method to synchronise - the
>benefits of automation are obvious. The downside is that this is not an
>actual syncing protocol, but the Opensync architecture looked like it
>might be able to accomodate the Gnokii style of doing things, since
>Opensync does so much synchronisation itself.
>
>
>  
>
Thats indeed very interesting. It would be possible to keep running 
opensync on a (maybe headless) machine and everytime your phone gets 
into the reach of the bluetooth connection it would get synchronized 
automatically.

>>It should work. But currently, the only problem is: if you change the data
>>on your phone, additional fields on the other device (i.e. on evolution),
>>will be dropped and your item on evolution will be replaced by the
>>"less rich" version from your phone.
>>
>>To avoid this, we need to implement a feature called "merging", that is
>>not supported by opensync, yet.
>>    
>>
>
>This is really important, I think. It would be a shame to lose any
>information. Especially since Gnokii interfaces not just with Nokia
>Series 60 phones, but also with more basic phones such as the Nokia
>Series 30 (e.g. 3210) and Series 40 (e.g. 6100) phones, which are less
>feature-rich than the Series 60 phones. 
>
>This presents many problems, some of which need to be fixed on the
>Gnokii side. The Gnokii project is rooted in the less modern phones
>rather than the Series 60 'smartphones', so there is not yet support for
>(e.g.) end dates in appointments, which screws things up as far as
>Evolution goes, since it will throw a wobbly at an appointment without
>an End date, and it's a bit pointless to assign an arbitrary one.
>
>However, the contact information is rich enough - this would be a good
>starting point.
>
>
>  
>
>>The number at the top would be the UID your plugin would report. 
>>    
>>
>
>Makes sense!
>
>  
>
>>The group id could be translated to a category, when converting the data to
>>a known format.
>>    
>>
>
>Likewise, makes sense.
>
>
>Hope that info has been of use - good luck with the merging stuff. I
>think that the utility of this plugin is contingent on that working, but
>I'll get working on what I can in the meantime. Are you planning that
>for the Beta release, by the way?
>
>  
>
The problem with merging is that it is _really_ complicated :) We first 
have to get the capabilities of each device so we know which fields are 
delete and which were just not supported. Then we have merge these 
information together with the data reported by the devices to 
distinguish which field of which device should be taken for the result. 
I think the real difficulty here is to find a way to describe the 
capabilities of the device in a efficient way.

I dont give an ETA for this feature yet, since the current top priority 
is the syncml plugin so we can finally get opensync to do something 
usefull :)

>Best wishes,
>Matt
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Opensync-users mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opensync-users
>  
>