You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(10) |
Apr
(30) |
May
(11) |
Jun
(8) |
Jul
(28) |
Aug
(113) |
Sep
(74) |
Oct
(43) |
Nov
(111) |
Dec
(31) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(70) |
Feb
(78) |
Mar
(110) |
Apr
(99) |
May
(106) |
Jun
(128) |
Jul
(65) |
Aug
(123) |
Sep
(80) |
Oct
(128) |
Nov
(80) |
Dec
(54) |
2007 |
Jan
(89) |
Feb
(83) |
Mar
(56) |
Apr
(56) |
May
(69) |
Jun
(29) |
Jul
(89) |
Aug
(44) |
Sep
(32) |
Oct
(114) |
Nov
(36) |
Dec
(46) |
2008 |
Jan
(88) |
Feb
(100) |
Mar
(63) |
Apr
(27) |
May
(39) |
Jun
(61) |
Jul
(35) |
Aug
(11) |
Sep
(9) |
Oct
(19) |
Nov
(28) |
Dec
(72) |
2009 |
Jan
(33) |
Feb
(4) |
Mar
(15) |
Apr
(24) |
May
(17) |
Jun
(17) |
Jul
(11) |
Aug
(30) |
Sep
(19) |
Oct
(8) |
Nov
(10) |
Dec
(5) |
2010 |
Jan
(5) |
Feb
(10) |
Mar
(12) |
Apr
(1) |
May
(8) |
Jun
(4) |
Jul
(9) |
Aug
(29) |
Sep
(6) |
Oct
(19) |
Nov
(4) |
Dec
(3) |
2011 |
Jan
(9) |
Feb
|
Mar
|
Apr
(7) |
May
(2) |
Jun
(9) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
(7) |
Dec
|
2012 |
Jan
(2) |
Feb
(5) |
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(9) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
From: Armin B. <arm...@de...> - 2005-07-17 17:19:04
|
Hi, i am glad to help you with the implementation of the java wrapper. I implemented parts of the python wrapper, so i already know how it should work. But i dont have any knowledge of java or the JNI... I think the c code is pretty much straigth forward. A good place to start is to take a look at the python wrapper to see how it is implemented. Armin Andy Mason wrote: > Hi, > After a discussion with some of the guys in #opensync, I'd like to > attempt to create a java-plugin API for opensync. Unfortunately my > knowledge of C++/ C is ...well..basically nothing. So I was wondering > if someone was interested in developing the C side of the API ? > > regards > Andrew M > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > _______________________________________________ > Opensync-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-users |
From: Andy M. <sla...@gm...> - 2005-07-17 15:49:11
|
Hi, After a discussion with some of the guys in #opensync, I'd like to attempt to create a java-plugin API for opensync. Unfortunately my knowledge of C++/ C is ...well..basically nothing. So I was wondering if someone was interested in developing the C side of the API ? regards=20 Andrew M |
From: Maciek B. <ma...@bo...> - 2005-07-14 06:30:08
|
On Wednesday 13 July 2005 22:45, Armin Bauer wrote: > > > > A question: what SyncML client stil uses wbxml these days? > > uh... i think its the other way round. which client _isnt_ using wbxml > these days? All high end Symbian based phones? They speak pure XML. > All mobile devices i know how can't even speak xml. They parse the wbxml > directly to save memory and bandwidth. I googled some more and it seems you are right: there is a numer of devices using wbxml (SE T610, Nokia 6600). Well, sorry for the noise. ./Maciek |
From: Armin B. <arm...@de...> - 2005-07-13 20:45:43
|
Maciek Borowka wrote: > On Wednesday 13 July 2005 20:19, Cornelius Schumacher wrote: > >>One question though: You use libwbxml, which changed its license from >>LGPL to GPL. Is there a way around that? Because it would be pretty >>pointless to have a non-GLP libsyncml, if it still requires a GPL >>library. > > > A question: what SyncML client stil uses wbxml these days? > uh... i think its the other way round. which client _isnt_ using wbxml these days? All mobile devices i know how can't even speak xml. They parse the wbxml directly to save memory and bandwidth. > I don't know of any, to be honest. In that case, we could live with the LGPL > fork (which is not going to be really used after all)... > > ./Maciek > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Opensync-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-users |
From: Maciek B. <ma...@bo...> - 2005-07-13 19:25:15
|
On Wednesday 13 July 2005 20:19, Cornelius Schumacher wrote: > One question though: You use libwbxml, which changed its license from > LGPL to GPL. Is there a way around that? Because it would be pretty > pointless to have a non-GLP libsyncml, if it still requires a GPL > library. A question: what SyncML client stil uses wbxml these days? I don't know of any, to be honest. In that case, we could live with the LGPL fork (which is not going to be really used after all)... ./Maciek |
From: Armin B. <arm...@de...> - 2005-07-13 19:07:00
|
Eduardo Pereira Habkost wrote: > Hi, > > On Wed, Jul 13, 2005 at 08:24:47PM +0200, Armin Bauer wrote: > >>Cornelius Schumacher wrote: > > <snip> > >>>One question though: You use libwbxml, which changed its license from >>>LGPL to GPL. Is there a way around that? Because it would be pretty >>>pointless to have a non-GLP libsyncml, if it still requires a GPL >>>library. >>> >> >>thats true of course. >> >>i see 3 possible solutions: >>- persuade the developer of libwbxml to change back to LGPL :) >>- dont change anything and live with it that we link against GPL >>- create a fork from version 0.8.9 (the current version is 0.9.0). I >>dont think that making the necessary changes to libwbxml would be too >>hard. (Of course i would not like this option out of respect for the >>developer of libwbxml) > > > I'm afraid the third option is the better one. > > I doubt we would convince > the libwbxml developer (IIRC, I know people who have tried it, but I am > not sure if they really contacted him). > > The second choice doesn't seem reasonable. > > I don't like having to fork, and I would like to have a better choice, > but it seems we don't have a better one (except the first one, if we > manage to convince him :). > > Anyway, I expect that the libwbxml author considered the risk of someone > doing this when he decided to change the license of libwbxml. > > We have another option: write a wbxml library from scratch, but this > doesn't seem to make sense as we already have a LGPL library available. > I dont think that writing from scratch is a good idea since the exisiting LGPL version of libwbxml is almost complete so the changes wouldnt be too large... so a fork should be pretty easy. The questions is of course how distributions would be handled since we then would need to get the new (LGPL) library into all distros under a new name. So i think convincing is by far the most convincing option :) > >>Any other possibilities? > > > I don't see any, unfortunately. > > >>Armin > > |
From: Eduardo P. H. <eha...@co...> - 2005-07-13 18:49:22
|
Hi, On Wed, Jul 13, 2005 at 08:24:47PM +0200, Armin Bauer wrote: >=20 > Cornelius Schumacher wrote: <snip> > > > >One question though: You use libwbxml, which changed its license from > >LGPL to GPL. Is there a way around that? Because it would be pretty > >pointless to have a non-GLP libsyncml, if it still requires a GPL > >library. > > >=20 > thats true of course. >=20 > i see 3 possible solutions: > - persuade the developer of libwbxml to change back to LGPL :) > - dont change anything and live with it that we link against GPL > - create a fork from version 0.8.9 (the current version is 0.9.0). I > dont think that making the necessary changes to libwbxml would be too > hard. (Of course i would not like this option out of respect for the > developer of libwbxml) I'm afraid the third option is the better one. I doubt we would convince the libwbxml developer (IIRC, I know people who have tried it, but I am not sure if they really contacted him). The second choice doesn't seem reasonable. I don't like having to fork, and I would like to have a better choice, but it seems we don't have a better one (except the first one, if we manage to convince him :). Anyway, I expect that the libwbxml author considered the risk of someone doing this when he decided to change the license of libwbxml. We have another option: write a wbxml library from scratch, but this doesn't seem to make sense as we already have a LGPL library available. >=20 > Any other possibilities? I don't see any, unfortunately. >=20 > Armin --=20 Eduardo |
From: Armin B. <arm...@de...> - 2005-07-13 18:25:33
|
Cornelius Schumacher wrote: > On Wednesday 13 July 2005 17:09, Armin Bauer wrote: > >>Ok, after i thought a bit about it and your persuasion work i changed >>the license to LGPL. :) > > > I think it's a good decision. I see a broad adoption as critical for the > OpenSync project. If device vendors or other third party developers > would be put off by the GPL, this would probably harm the project more > than the missed opportunity to sell some licenses. I'm sure there are > other ways to base a business model on OpenSync. > > One question though: You use libwbxml, which changed its license from > LGPL to GPL. Is there a way around that? Because it would be pretty > pointless to have a non-GLP libsyncml, if it still requires a GPL > library. > thats true of course. i see 3 possible solutions: - persuade the developer of libwbxml to change back to LGPL :) - dont change anything and live with it that we link against GPL - create a fork from version 0.8.9 (the current version is 0.9.0). I dont think that making the necessary changes to libwbxml would be too hard. (Of course i would not like this option out of respect for the developer of libwbxml) Any other possibilities? Armin |
From: Cornelius S. <sch...@kd...> - 2005-07-13 18:18:02
|
On Wednesday 13 July 2005 17:09, Armin Bauer wrote: > Ok, after i thought a bit about it and your persuasion work i changed > the license to LGPL. :) I think it's a good decision. I see a broad adoption as critical for the OpenSync project. If device vendors or other third party developers would be put off by the GPL, this would probably harm the project more than the missed opportunity to sell some licenses. I'm sure there are other ways to base a business model on OpenSync. One question though: You use libwbxml, which changed its license from LGPL to GPL. Is there a way around that? Because it would be pretty pointless to have a non-GLP libsyncml, if it still requires a GPL library. -- Cornelius Schumacher <sch...@kd...> |
From: Armin B. <arm...@de...> - 2005-07-13 16:20:13
|
Hi, pro-linux.de, a large german linux related website just release an article about libsyncml. see it here (in german): http://www.pro-linux.de/news/2005/8392.html translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.pro-linux.de%2Fnews%2F2005%2F8392.html&langpair=de%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools Armin |
From: Hubert F. <hfi...@te...> - 2005-07-13 15:12:23
|
Armin Bauer wrote: > Ok, after i thought a bit about it and your persuasion work i changed > the license to LGPL. :) > Just don't make any mistake. I was not trying to persuade you. Just trying to give some fact, as I myself faced the problem recently, given might be the more important to you. Hub |
From: Armin B. <arm...@de...> - 2005-07-13 15:09:54
|
Ok, after i thought a bit about it and your persuasion work i changed the license to LGPL. :) Hubert Figuiere wrote: > Armin Bauer wrote: > >> So i think the whole GPL vs. LGPL boils down to the question: >> Which is better for the project? A possible higher userbase with >> companies using the library which might return something in the future >> or a maybe lower userbase but a possible source of income for the >> project? > > > My opinion: > > If you want OpenSync to be adopted by projects like GNOME, libraries > cannot be GPL. This is part of the policy of GNOME. > > I myself asked the question about a project I'm working on. I was really > willing to make the library GPL, but for the sole reason of being able > to use it in GNOME, I decided for LGPL. That still allow proprietary > vendor to link against it. > > Just my CDN $.02 > > Hub |
From: Hubert F. <hfi...@te...> - 2005-07-12 14:19:05
|
Armin Bauer wrote: > So i think the whole GPL vs. LGPL boils down to the question: > Which is better for the project? A possible higher userbase with > companies using the library which might return something in the future > or a maybe lower userbase but a possible source of income for the project? My opinion: If you want OpenSync to be adopted by projects like GNOME, libraries cannot be GPL. This is part of the policy of GNOME. I myself asked the question about a project I'm working on. I was really willing to make the library GPL, but for the sole reason of being able to use it in GNOME, I decided for LGPL. That still allow proprietary vendor to link against it. Just my CDN $.02 Hub |
From: Armin B. <arm...@de...> - 2005-07-12 09:52:12
|
Helge Hess wrote: > On Jul 12, 2005, at 11:20, Armin Bauer wrote: > >> the only thing i used is the libsyncml project space, not the code. So >> far all code in the libsyncml library is writen by myself. > > > OK, I misunderstood that. > >> I choose the GPL for a simple reason: I dont want that the library is >> used for a commercial product without the duty to return something to >> the community which could either be open sourcing their own code (so >> that i can be linked against GPL code) or by buying a commercial license. > > > You probably meant proprietary, not commercial. If the proprietary > product improves the library itself it needs to deliver the bugfixes and > enhancement to that even with LGPL. And increasing the user base for the > library is IMHO a good thing (a lot more people can use your library if > its LGPL). Yes i meant propietary of course. > > But its your decision, I suppose you plan to make money with commercial > licenses. Yes, i think it would not be wise not to try. But if money would come in from commercial licenses it would definetly be used for the project (like paying server/bandwidth or buying test equipment etc). So i think the whole GPL vs. LGPL boils down to the question: Which is better for the project? A possible higher userbase with companies using the library which might return something in the future or a maybe lower userbase but a possible source of income for the project? > >> Just out of curiosity, is there anything that would _require_ a LGPL >> license or is it just that the GPL is too restrictive? > > > Not being able to use the library in a server with a commercial plugin > at the same time is certainly quite a big drawback. > I would prefer something LGPL to avoid artificial workarounds for that. > > Greets, > Helge |
From: Helge H. <hel...@op...> - 2005-07-12 09:31:48
|
On Jul 12, 2005, at 11:20, Armin Bauer wrote: > the only thing i used is the libsyncml project space, not the code. So > far all code in the libsyncml library is writen by myself. OK, I misunderstood that. > I choose the GPL for a simple reason: I dont want that the library is > used for a commercial product without the duty to return something to > the community which could either be open sourcing their own code (so > that i can be linked against GPL code) or by buying a commercial > license. You probably meant proprietary, not commercial. If the proprietary product improves the library itself it needs to deliver the bugfixes and enhancement to that even with LGPL. And increasing the user base for the library is IMHO a good thing (a lot more people can use your library if its LGPL). But its your decision, I suppose you plan to make money with commercial licenses. > Just out of curiosity, is there anything that would _require_ a LGPL > license or is it just that the GPL is too restrictive? Not being able to use the library in a server with a commercial plugin at the same time is certainly quite a big drawback. I would prefer something LGPL to avoid artificial workarounds for that. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org |
From: Armin B. <arm...@de...> - 2005-07-12 09:20:25
|
Helge Hess wrote: > On Jul 8, 2005, at 21:45, Armin Bauer wrote: > >> i just finished setting up the libsyncml project space at >> http://libsyncml.opensync.org. > > > Is this library suitable for server side implementations as well or is > it focused on clients? > The library consists of several layers. The lowest layers are the transport like http client, http server, obex client etc The next layer is responisble for parsing the data and dispatching them. The highest layers consists of objects which can be registered with a session at a specific path. At the moment there are: - a authentication object that receives incoming SyncHdrs and authenticates the user if necessary - a devinf object - a syncml Ds server which implements the server part of the ds protocol and which receives commands like alert, sync, map etc - a syncml ds client which implements the client part of ds (not yet implemented) so the library will be usable as both server and client by using different parts of the library >> And i also got the libsyncml project at sf.net donated by Max. Thanks >> for this. > > > Personally I would be surprised if Max had something against relicensing > the code under LGPL if its currently under GPL. > I agree with the others that this would be quite important. > the only thing i used is the libsyncml project space, not the code. So far all code in the libsyncml library is writen by myself. I choose the GPL for a simple reason: I dont want that the library is used for a commercial product without the duty to return something to the community which could either be open sourcing their own code (so that i can be linked against GPL code) or by buying a commercial license. Just out of curiosity, is there anything that would _require_ a LGPL license or is it just that the GPL is too restrictive? > Greets, > Helge |
From: Helge H. <hel...@op...> - 2005-07-12 08:00:48
|
On Jul 8, 2005, at 21:45, Armin Bauer wrote: > i just finished setting up the libsyncml project space at > http://libsyncml.opensync.org. Is this library suitable for server side implementations as well or is it focused on clients? > And i also got the libsyncml project at sf.net donated by Max. Thanks > for this. Personally I would be surprised if Max had something against relicensing the code under LGPL if its currently under GPL. I agree with the others that this would be quite important. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org |
From: Dave H. <dav...@mb...> - 2005-07-12 02:56:07
|
Hi Hubert, On Mon, 2005-07-11 at 22:36 -0400, Hubert Figuiere wrote: > On Tue, 2005-07-12 at 12:24 +1000, Dave Hall wrote: > > Hi Dan, > > > > On Mon, 2005-07-11 at 18:21 -0700, Dan Mosedale wrote: > > > I did notice that libsyncml is GPL, while opensync itself is > > > LGPL. Won't this cause a problem for folks that want to ship opensync > > > itself under the LGPL but not the GPL? > > > > There is no problem linking GPL and LGPL code. > > > > As long as the documentation is clear, then there will no issue. As > > both licenses require distribution of the source, it should be clear to > > anyone working on the code what the deal is. > > But it can be a problem. For example to be shipped in GNOME, it would > have to be a LGPL library, because that is a requirement. > Or if you want to write a conduit for OpenSync that link against > something that is not GPL compatible. I spoke to Dan on #calendar on irc.mozilla.org to discuss the what he really meant. There is no issue if you build a conduit which links to non free code, as long as you don't distribute a binary version. You (or anyone else) can build it from source and have no issues. Alternatively you could remove the libsyncml code and distribute a binary version. Either way it is a pita for a vendor of non free software who wants to link to opensync with libsyncml support. I see the point people are making. Sorry for misunderstanding the original question. Cheers Dave |
From: Hubert F. <hfi...@te...> - 2005-07-12 02:38:08
|
On Tue, 2005-07-12 at 12:24 +1000, Dave Hall wrote: > Hi Dan, > > On Mon, 2005-07-11 at 18:21 -0700, Dan Mosedale wrote: > > I did notice that libsyncml is GPL, while opensync itself is > > LGPL. Won't this cause a problem for folks that want to ship opensync > > itself under the LGPL but not the GPL? > > There is no problem linking GPL and LGPL code. > > As long as the documentation is clear, then there will no issue. As > both licenses require distribution of the source, it should be clear to > anyone working on the code what the deal is. But it can be a problem. For example to be shipped in GNOME, it would have to be a LGPL library, because that is a requirement. Or if you want to write a conduit for OpenSync that link against something that is not GPL compatible. These problems should be understood. Hub -- Crazy French - http://www.figuiere.net/hub/ |
From: Dave H. <dav...@mb...> - 2005-07-12 02:26:01
|
Hi Dan, On Mon, 2005-07-11 at 18:21 -0700, Dan Mosedale wrote: > I did notice that libsyncml is GPL, while opensync itself is > LGPL. Won't this cause a problem for folks that want to ship opensync > itself under the LGPL but not the GPL? There is no problem linking GPL and LGPL code. As long as the documentation is clear, then there will no issue. As both licenses require distribution of the source, it should be clear to anyone working on the code what the deal is. Cheers Dave |
From: Dan M. <dm...@mo...> - 2005-07-12 01:21:46
|
Armin Bauer wrote: > Hi, > > i just finished setting up the libsyncml project space at > http://libsyncml.opensync.org. > > If you are interested at the project or maybe even like to help, go take > a look :) All support is always welcome. Very cool. I did notice that libsyncml is GPL, while opensync itself is LGPL. Won't this cause a problem for folks that want to ship opensync itself under the LGPL but not the GPL? Dan |
From: Armin B. <arm...@de...> - 2005-07-08 19:46:15
|
Hi, i just finished setting up the libsyncml project space at http://libsyncml.opensync.org. If you are interested at the project or maybe even like to help, go take a look :) All support is always welcome. And i also got the libsyncml project at sf.net donated by Max. Thanks for this. The initial code for the syncml plugin is now also hosted at the opensync project at svn.opensync.org/plugins/syncml/ so the syncml is definetly getting closer! Armin |
From: Armin B. <arm...@de...> - 2005-07-04 20:25:28
|
Eduardo Pereira Habkost wrote: > On Wed, Jun 29, 2005 at 12:08:02PM +0200, Somlyai Tamás wrote: > >>Hello everyone! > > > Hi, welcome! :) > > >>I'm just subscribed to the mailinglist and I'm offering my help for bug >>hunting, and any other things. I am a 20 years old student, and studying in >>Hungary at the Eötvös Loránd University of Science as a programmer. I'm also >>working as a journalist, and I'm writing reviews about the latest mobile >>phones and sometimes PDAs, so I can test opensync and it's plugins with these >>devices. >>Is there any IRC room for opensync? Maybe we can start a #opensync at >>freenode. > > > There is not an #opensync channel, yet. But we (Armin and me, at least), > often stay on #multisync at freenode. > not correct anymore. :) a few days ago we opened the #opensync channel on freenode and everyone is invited to join! |
From: Eduardo P. H. <eha...@co...> - 2005-07-04 19:37:32
|
On Wed, Jun 29, 2005 at 12:08:02PM +0200, Somlyai Tam=E1s wrote: > Hello everyone! Hi, welcome! :) >=20 > I'm just subscribed to the mailinglist and I'm offering my help for bug= =20 > hunting, and any other things. I am a 20 years old student, and studying = in=20 > Hungary at the E=F6tv=F6s Lor=E1nd University of Science as a programmer.= I'm also=20 > working as a journalist, and I'm writing reviews about the latest mobile= =20 > phones and sometimes PDAs, so I can test opensync and it's plugins with t= hese=20 > devices. > Is there any IRC room for opensync? Maybe we can start a #opensync at=20 > freenode. There is not an #opensync channel, yet. But we (Armin and me, at least), often stay on #multisync at freenode. --=20 Eduardo |
From: Eduardo P. H. <eha...@co...> - 2005-07-04 19:36:04
|
On Tue, Jun 14, 2005 at 04:45:53PM +1000, Cameron McCormack wrote: > Hi. Hi, Cameron, Sorry for the (very) late reply, >=20 > I'd like to get some synchronisation happening between my phone and my > computer, at least, but I have a question first. My phone (SE T68i) > stores very limited information in its contacts. It has fields for > Name, Home, Work, Mobile, Fax, Other and E-mail. Quite often, I will > have phone numbers that don't fit into this scheme nicely, and I end up > squeezing, for example, a person's second mobile number into the Other > field. In a different contact, I might use the Other field for some > other purpose, like their work's switchboard number. Anyway, the point > is that I use this Other field on the phone in a variety of ways, > depending on the contact, while on my computer I have my contacts stored > in an XML file of my own devising where there is no such ambiguity. >=20 > Is it possible to have complex mapping rules with opensync such that if > I have a second mobile number in my XML file for a contact, that number > will go in to the Other field on my phone? And if I originally enter a > number into the Other field on the phone then it shouldn't be assumed > that it is a second mobile number necessarily, and gets turned into a > generic "other" number in my XML file (to be later corrected by me by > hand if necessary)? The conversion between the fields on opensync is made by functions implemented by "format plugins". They just make a simple mapping between the fields, but you can make a "smarter" function for your specific format and device, if you want. The current functions implemented by most plugins are not so smart and support complex rules, but they may be changed to allow that. Your conversion function can do anything you want, with some limitations, for example: you can't ask a question to the user easily. Actually, I would say that you cannot interact with the user on the conversion function, unless opensync is extended to allow some interaction to tune the conversion function behaviour. Maybe, if we want a more complex behaviour, we may need to store the fields mapping somewhere, so the engine know which field on member-A was stored on a field on member-B. I guess this may be a possible future improvement for opensync (or, if we want to keep this outside opensync, on the default format plugins). >=20 > Another issue is that in my XML contacts file I specify the person's > family and given names, as well as a display name. I want my phone to > have an entry called "Dad" rather than my father's full name, while in > my file I will have some markup like >=20 > <contact> > <name> > <family-name>McCormack</family-name> > <given-name>Alex</given-name> > </name> > <display-name>Dad</display-name> > <!-- ... --> > </contact> >=20 > Since on the phone it appears as a single Name field, I want to copy the > display name (and use that for identity checking purposes) to the phone > if one exists, otherwise it should copy the given name, a space, then > the family name. If the contact is being copied from the phone to the > XML file, and it doesn't exist in the file yet, then it can default to > guessing that I entered it as given name, space, family name. Some of > the people in my contacts file though have names where the family name > comes first, such as Chinese names. Though it may be inconsistent for > searching on my phone, I want to have those listed as family name, > space, given name. The fact that the name should be displayed with > family name first is specified with an attribute in my XML file. >=20 > Hopefully I can do this with opensync. If not I might have to upgrade > my phone. ;-) Of course I don't expect support to be added for my > bespoke XML file format, just that it is possible for me to write a > plugin that supports the complex field mapping that I would like. Yes, you may write a format plugin as complex as you want. It seems you can do what you want with the current format conversion architecture on opensync. :) --=20 Eduardo |