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 |