Menu
▾
▴
opensync-users
|
From: Matthew K. <m_...@fa...> - 2005-04-25 17:53:29
|
Hi all, I've written some Python code to help me back up my addressbook from my phone, using gnokii. I'd love to help Opensync by augmenting this into an Opensync plugin. However, there are a few preliminary things I wanted to raise. Firstly, the best thing is presumably to convert the information from gnokii into your XML format. However, I haven't been able to find the documentation on this format - could you direct me to it? Also, the information you get from gnokii is much less rich than the information you get from evolution, for instance. For example, there's no birthday field from gnokii. How does that sort of consideration affect a plugin? Typically, you get this sort of info from a gnokii plugin: 159. Name: Kay Matt Number: +44xxxxxxxxxxx Group id: 5 Preferred number: +44xxxxxxxxxxx Cellular number: +44xxxxxxxxxxx Email address: m_...@fa... Business number: +44xxxxxxxxxxxx Home number: +44xxxxxxxxxxxx Notes: blabla The number at the top (here, 159) is the memory location in the phone where the entry is stored. This is needed when you want to overwrite an entry in the phone - you can't just direct it by name. The group ID is something specific to the phone and wouldn't need to be synchronised - it's the friends/family thing. Do you think it's feasible to do this? I might need a bit of helpful advice with writing the plugin, but would be happy to give it a go. Best wishes, Matt |
|
From: Eduardo P. H. <eha...@co...> - 2005-04-25 18:37:32
|
On Mon, Apr 25, 2005 at 06:53:22PM +0100, Matthew Kay wrote: > Hi all, Hi, Matthew, >=20 > I've written some Python code to help me back up my addressbook from my > phone, using gnokii. I'd love to help Opensync by augmenting this into > an Opensync plugin. However, there are a few preliminary things I wanted > to raise. Do you know which protocol does gnokii implement, to access your phone? >=20 > Firstly, the best thing is presumably to convert the information from > gnokii into your XML format. However, I haven't been able to find the > documentation on this format - could you direct me to it? Not necessarily. You tell opensync on which format the data you reported is. You can use the existing formats (e.g. "vcard"), or write a plugin for your own format. The xml format is mostly used internally, as it isn't even reported as plain xml, but a libxml2 xmlDoc object on memory. If you plan to write your plugin in python (and test our brand new [untested] python plugin support code :), the better option would be just report the data as vcard, because it wouldn't be possible to report the xml format, as it is expected to be a C struct. I don't know if the xml format is documented, somewhere. I am used to look at the sources to check which fields should be set. Armin may give you more information. So, you have two choices: - Convert the data to vcard or the xml format before reporting it to opensync. This is the "quick" way, as you just need to write your plugin and not care about making a format-plugin - Report the data in the format that is reported by your device, or by gnokii, and write a format-plugin to handle this format and and provide functions convert it from/to an already supported format. Then the gnokii-plugin would report the data on this format, and the conversion code on opensync will convert it to the right format when writing it to other devices. This is the preferred way of handling data on other formats, but has the additional work of writing the format plugin, and then write your gnokii plugin. But it shouldn't be so complex, as for the previous approach, you'll need to write a conversion function from gnokii to a know format, anyway Again, if you plan to write your plugin in python, you'll need to choose the first approach, because format-plugins in python aren't supported, currently. >=20 > Also, the information you get from gnokii is much less rich than the > information you get from evolution, for instance. For example, there's > no birthday field from gnokii. How does that sort of consideration > affect a plugin? 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. >=20 > Typically, you get this sort of info from a gnokii plugin: >=20 > 159. Name: Kay Matt > Number: +44xxxxxxxxxxx > Group id: 5 > Preferred number: +44xxxxxxxxxxx > Cellular number: +44xxxxxxxxxxx > Email address: m_...@fa... > Business number: +44xxxxxxxxxxxx > Home number: +44xxxxxxxxxxxx > Notes: blabla >=20 > The number at the top (here, 159) is the memory location in the phone > where the entry is stored. This is needed when you want to overwrite an > entry in the phone - you can't just direct it by name. The group ID is > something specific to the phone and wouldn't need to be synchronised - > it's the friends/family thing. The number at the top would be the UID your plugin would report. The group id could be translated to a category, when converting the data to a known format. >=20 > Do you think it's feasible to do this? I might need a bit of helpful > advice with writing the plugin, but would be happy to give it a go. I think it is really feasible. But I guess it would be better to write a plugin for the protocol your phone uses. But I am not sure what would be better, as I don't know how gnokii works, and which protocols it supports. >=20 > Best wishes, > Matt >=20 --=20 Eduardo |
|
From: Matthew K. <m_...@fa...> - 2005-04-25 20:46:04
|
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. 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. > 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? Best wishes, Matt |
|
From: Armin B. <arm...@de...> - 2005-04-26 07:32:48
|
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 > > |
|
From: Armin B. <arm...@de...> - 2005-04-26 07:19:47
|
Eduardo Pereira Habkost wrote: >On Mon, Apr 25, 2005 at 06:53:22PM +0100, Matthew Kay wrote: > > >>Hi all, >> >> > >Hi, Matthew, > > > >>I've written some Python code to help me back up my addressbook from my >>phone, using gnokii. I'd love to help Opensync by augmenting this into >>an Opensync plugin. However, there are a few preliminary things I wanted >>to raise. >> >> > >Do you know which protocol does gnokii implement, to access your phone? > > > >>Firstly, the best thing is presumably to convert the information from >>gnokii into your XML format. However, I haven't been able to find the >>documentation on this format - could you direct me to it? >> >> > >Not necessarily. You tell opensync on which format the data you reported >is. You can use the existing formats (e.g. "vcard"), or write a plugin >for your own format. The xml format is mostly used internally, as it >isn't even reported as plain xml, but a libxml2 xmlDoc object on memory. > >If you plan to write your plugin in python (and test our brand new >[untested] python plugin support code :), the better option would be just >report the data as vcard, because it wouldn't be possible to report >the xml format, as it is expected to be a C struct. > > Actually thats not completely true. While the xml format does use the libxml c struct and cannot be accessed easily by a python plugin, it would _very_ easy to write a new format "xml plain" which is the same xml but saved into a string. The converter to do this would be a simple xmlParse to go from plain to xml and a xmlDumpMemory to go from xml to plain. The plain xml could then easily be created by the python plugin (its just a string after all) >I don't know if the xml format is documented, somewhere. I am used to >look at the sources to check which fields should be set. Armin may give >you more information. > >So, you have two choices: > >- Convert the data to vcard or the xml format before reporting it > to opensync. This is the "quick" way, as you just need to write > your plugin and not care about making a format-plugin > >- Report the data in the format that is reported by your device, or > by gnokii, and write a format-plugin to handle this format and and > provide functions convert it from/to an already supported format. Then > the gnokii-plugin would report the data on this format, and the > conversion code on opensync will convert it to the right format when > writing it to other devices. This is the preferred way of handling > data on other formats, but has the additional work of writing the > format plugin, and then write your gnokii plugin. But it shouldn't > be so complex, as for the previous approach, you'll need to write > a conversion function from gnokii to a know format, anyway > >Again, if you plan to write your plugin in python, you'll need to choose >the first approach, because format-plugins in python aren't supported, >currently. > > > >>Also, the information you get from gnokii is much less rich than the >>information you get from evolution, for instance. For example, there's >>no birthday field from gnokii. How does that sort of consideration >>affect a plugin? >> >> > >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. > > > >>Typically, you get this sort of info from a gnokii plugin: >> >>159. Name: Kay Matt >>Number: +44xxxxxxxxxxx >>Group id: 5 >>Preferred number: +44xxxxxxxxxxx >>Cellular number: +44xxxxxxxxxxx >>Email address: m_...@fa... >>Business number: +44xxxxxxxxxxxx >>Home number: +44xxxxxxxxxxxx >>Notes: blabla >> >>The number at the top (here, 159) is the memory location in the phone >>where the entry is stored. This is needed when you want to overwrite an >>entry in the phone - you can't just direct it by name. The group ID is >>something specific to the phone and wouldn't need to be synchronised - >>it's the friends/family thing. >> >> > >The number at the top would be the UID your plugin would report. The >group id could be translated to a category, when converting the data to >a known format. > > > >>Do you think it's feasible to do this? I might need a bit of helpful >>advice with writing the plugin, but would be happy to give it a go. >> >> > >I think it is really feasible. But I guess it would be better to write a >plugin for the protocol your phone uses. But I am not sure what would be >better, as I don't know how gnokii works, and which protocols it supports. > > > >>Best wishes, >>Matt >> >> >> > > > |
|
From: Pawel K. <pk...@be...> - 2005-04-26 13:38:33
|
On Mon, 25 Apr 2005, Eduardo Pereira Habkost wrote: Hi, >> I've written some Python code to help me back up my addressbook from my >> phone, using gnokii. I'd love to help Opensync by augmenting this into >> an Opensync plugin. However, there are a few preliminary things I wanted >> to raise. > > Do you know which protocol does gnokii implement, to access your phone? It depends on the phone. It may be either FBUS, MBUS protocols, AT commands or gnapplet binary protocol (defined internally by gnokii). take care, pkot -- p k o t a t b e z s e n s u d o t p l http://www.gnokii.org/ |
|
From: Michal S. <re...@at...> - 2005-04-27 11:00:59
|
BTW: there's also gnokii plugin for multisync written by Balint Reczey <bal...@ya...> and he also considered porting to opensync. So you may try to coordinate the effort for the opensync plugin in order to create one solution ... The sources are already available in SF CVS: http://cvs.sourceforge.net/viewcvs.py/multisync/multisync/plugins/gnokii_sync/?only_with_tag=branch_08X Regards Michal On Tue, 26 Apr 2005, Pawel Kot wrote: > On Mon, 25 Apr 2005, Eduardo Pereira Habkost wrote: > > Hi, > >>> I've written some Python code to help me back up my addressbook from my >>> phone, using gnokii. I'd love to help Opensync by augmenting this into >>> an Opensync plugin. However, there are a few preliminary things I wanted >>> to raise. >> >> Do you know which protocol does gnokii implement, to access your phone? > > It depends on the phone. It may be either FBUS, MBUS protocols, AT commands > or gnapplet binary protocol (defined internally by gnokii). > > take care, > pkot > -- > p k o t a t b e z s e n s u d o t p l > http://www.gnokii.org/ > > > ------------------------------------------------------- > 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 > |
|
From: David E. <tw...@us...> - 2005-04-26 07:33:39
|
On Mon, 2005-04-25 at 18:53 +0100, Matthew Kay wrote:
> Hi all,
>
> I've written some Python code to help me back up my addressbook from my
> phone, using gnokii. I'd love to help Opensync by augmenting this into
> an Opensync plugin. However, there are a few preliminary things I wanted
> to raise.
>
> Firstly, the best thing is presumably to convert the information from
> gnokii into your XML format. However, I haven't been able to find the
> documentation on this format - could you direct me to it?
I also think you should use the XML format. For contacts it is basically
the vCard properties but in XML, but using the XML format will make you
independent of vCard parsing and such.
The best documentation is the xml-vcard.c source code ... :-)
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
|
|
From: Pawel K. <pk...@be...> - 2005-04-26 08:30:17
|
On Tue, 26 Apr 2005, David Eriksson wrote: > On Mon, 2005-04-25 at 18:53 +0100, Matthew Kay wrote: >> Hi all, >> >> I've written some Python code to help me back up my addressbook from my >> phone, using gnokii. I'd love to help Opensync by augmenting this into >> an Opensync plugin. However, there are a few preliminary things I wanted >> to raise. >> >> Firstly, the best thing is presumably to convert the information from >> gnokii into your XML format. However, I haven't been able to find the >> documentation on this format - could you direct me to it? > > I also think you should use the XML format. For contacts it is basically > the vCard properties but in XML, but using the XML format will make you > independent of vCard parsing and such. > > The best documentation is the xml-vcard.c source code ... :-) Extending gnokii with xml output for vcal/vcard should be a fairly easy thing. take care, pkot -- p k o t a t b e z s e n s u d o t p l http://www.gnokii.org/ |
|
From: Matthew K. <m_...@fa...> - 2005-04-26 10:19:31
|
Glad you're on this list, Pawel! Glad people think this is a good idea. I'm fine with converting to XML in the plugin, that should be very easy (especially in Python) , and I'll look at the code David suggested for the API. Sadly, I've got exams at Imperial College, London over the next few weeks so I'm unlikely to get started on it right away - if anyone else is enthused, by all means go ahead and report to the list! I had a thought about merging. Obviously it is a complete nightmare trying to get the specific capabilities of each device, but perhaps that's something that you could leave to the user, say by getting them to configure the plugin via an XML file or the GUI as to which fields their device can handle? For the Gnokii plugin, this problem is simplified - the restriction is not so much the phones themselves as the gnokii application, so you could provide the users for presets (Gnokii-series 60, Gnokii-series 40 etc.). These could be updated on the plugin side as Gnokii development progressed. This is one more advantage of the server/client architecture rather than dealing with the phone directly - you are given predictable output. But, I can well imagine that it's a big coding job - good luck with the SyncML plugin, I think that you Opensync developers are making something really good. The decision to start something completely new and ambitious (rather than sticking with Multisync 0.8x) is really starting to pay off, I think. Best wishes, Matt -- M.Sc. Computer Science student Imperial College, London 256a Archway Road, London, N6 5AX tel 07717 204242 |
|
From: Armin B. <arm...@de...> - 2005-04-26 10:42:12
|
Matthew Kay wrote: >Glad you're on this list, Pawel! > >Glad people think this is a good idea. I'm fine with converting to XML >in the plugin, that should be very easy (especially in Python) , and >I'll look at the code David suggested for the API. > >Sadly, I've got exams at Imperial College, London over the next few >weeks so I'm unlikely to get started on it right away - if anyone else >is enthused, by all means go ahead and report to the list! > >I had a thought about merging. Obviously it is a complete nightmare >trying to get the specific capabilities of each device, but perhaps >that's something that you could leave to the user, say by getting them >to configure the plugin via an XML file or the GUI as to which fields >their device can handle? For the Gnokii plugin, this problem is >simplified - the restriction is not so much the phones themselves as the >gnokii application, so you could provide the users for presets >(Gnokii-series 60, Gnokii-series 40 etc.). These could be updated on the >plugin side as Gnokii development progressed. This is one more advantage >of the server/client architecture rather than dealing with the phone >directly - you are given predictable output. > > i think opensync should be as easy to use for the user as possible, so if there was a way to have less options for the user i would go this way. Instead of a drop down menu where the user has to pick his phone this should be detected. each phone will tell what it is somewhere and this should be used to report the correct capabilities. I think there could be an even better approach (at least for the user and for the plugin developers): auto detection. We would generate a xml contact for example that has all available fields set. Then we send it to the device and query it again afterwards. Now we just have to compare which fields are missing. We could even implement a caching mechanism for this so we dont have to do this when we see a "known" phone. >But, I can well imagine that it's a big coding job - good luck with the >SyncML plugin, I think that you Opensync developers are making something >really good. The decision to start something completely new and >ambitious (rather than sticking with Multisync 0.8x) is really starting >to pay off, I think. > > > I sure hope so :) >Best wishes, >Matt >-- >M.Sc. Computer Science student >Imperial College, London > >256a Archway Road, >London, >N6 5AX > >tel 07717 204242 > > > >------------------------------------------------------- >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 > > |
|
From: Alan S. <ala...@po...> - 2005-04-26 13:03:01
Attachments:
PGP.sig
|
Le 26 avr. 05, =E0 09:33, David Eriksson a =E9crit : > I also think you should use the XML format. For contacts it is=20 > basically > the vCard properties but in XML, but using the XML format will make = you > independent of vCard parsing and such. > > The best documentation is the xml-vcard.c source code ... :-) I am very interested by XML based formats for PIM tools. Is this code=20 following some XML-vcard standard? Alan Schmitt |
|
From: David E. <tw...@us...> - 2005-04-26 13:15:29
|
On Tue, 2005-04-26 at 15:02 +0200, Alan Schmitt wrote: > Le 26 avr. 05, =E0 09:33, David Eriksson a =E9crit : >=20 > > I also think you should use the XML format. For contacts it is=20 > > basically > > the vCard properties but in XML, but using the XML format will make y= ou > > independent of vCard parsing and such. > > > > The best documentation is the xml-vcard.c source code ... :-) >=20 > I am very interested by XML based formats for PIM tools. Is this code=20 > following some XML-vcard standard? As far as I know, the XML is just meant to properly represent anything that a "MIME directory" (RFC something) can contain, with named tags for known properties (RFC this and that for vCard, vEvent, vTodo). I plan to patch xml-vcard.c to use these #defines instead of the literals for the tag names: http://www.2good.nu/blandat/opensync-xml-contact.h However, Armin rewrote xml-vcard.c before I comitted the work I had done, and I havent updated it yet...=20 If someone has more time to spare than I, feel free to submit a patch! --=20 Regards, -\- David Eriksson -/- SynCE - http://synce.sourceforge.net ScummVM - http://scummvm.sourceforge.net Desquirr - http://desquirr.sourceforge.net |
|
From: Armin B. <arm...@de...> - 2005-04-26 21:46:51
Attachments:
signature.asc
|
David Eriksson wrote: > On Tue, 2005-04-26 at 15:02 +0200, Alan Schmitt wrote: > >>Le 26 avr. 05, à 09:33, David Eriksson a écrit : >> >> >>>I also think you should use the XML format. For contacts it is >>>basically >>>the vCard properties but in XML, but using the XML format will make you >>>independent of vCard parsing and such. >>> >>>The best documentation is the xml-vcard.c source code ... :-) >> >>I am very interested by XML based formats for PIM tools. Is this code >>following some XML-vcard standard? > > > As far as I know, the XML is just meant to properly represent anything > that a "MIME directory" (RFC something) can contain, with named tags for > known properties (RFC this and that for vCard, vEvent, vTodo). > Thats basically right. But it is not supposed to only represent the mime dir related content, but "all" content available (read: the information stored in the xml-contact is the set union of the information available on all other formats). Therefore this format will be somewhat dynamical and will change over time. > I plan to patch xml-vcard.c to use these #defines instead of the > literals for the tag names: > > http://www.2good.nu/blandat/opensync-xml-contact.h > > However, Armin rewrote xml-vcard.c before I comitted the work I had > done, and I havent updated it yet... ups. didnt know about this patch when i made my changes, sorry! Ill try to do the fixes when i find some time. see: http://www.opensync.org/ticket/82 > > If someone has more time to spare than I, feel free to submit a patch! > |
|
From: Pawel K. <pk...@be...> - 2005-04-26 08:29:13
|
On Mon, 25 Apr 2005, Matthew Kay wrote: Hi, > Typically, you get this sort of info from a gnokii plugin: > > 159. Name: Kay Matt > Number: +44xxxxxxxxxxx > Group id: 5 > Preferred number: +44xxxxxxxxxxx > Cellular number: +44xxxxxxxxxxx > Email address: m_...@fa... > Business number: +44xxxxxxxxxxxx > Home number: +44xxxxxxxxxxxx > Notes: blabla > > The number at the top (here, 159) is the memory location in the phone > where the entry is stored. This is needed when you want to overwrite an > entry in the phone - you can't just direct it by name. The group ID is > something specific to the phone and wouldn't need to be synchronised - > it's the friends/family thing. I think it may be usable as well -- eg. when you want to synchronize between the phones and keep the caller groups remain. As we already talked on gnokii-ml, the gnokii structure is a subject to be extended. pkot -- p k o t a t b e z s e n s u d o t p l http://www.gnokii.org/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X