re #10 no, KDE does not store everything in one big field, it only stores the street data in that field. What's more is that I do not see how Evoluation does use the ext data visually... About concatening though, I find it horribly horribly horribly awful. How do you sync that if user changed the ext on his phone and the ext part on his desktop in different ways, I suspect it will be difficult to detach the ext data from the street without any guidance where to split. That said, what to do if the user changed the address data in such a way that the ext data is unrecognizable? Taking the whole data and stuff it into address1 is probably no option because the user might be ext aware and have provided an ext and expects it to show up as such on his phone. I really do not think that glueing things together in the implementation is a good idea, especially if you consider that at some point more implements are around. If there is a common flaw in all of them, they all need to be fixed instead of fixing it once for all.
And yes, someone is (or in this case will be) working on Akoandi support https://wiki.kubuntu.org/GSoC/2010/HaraldSitter + I think you should keep those options in mind eitherway. re #12 I seem to have missed that. Anyhow, the problem is that no UI exposes the ext field, most likely because the addressee class does not directly expose this interface. Time to poke upstream I suppose... -- Data loss of postal addresses between Evolution and Ubuntu One's Funambol exchange/web UI https://bugs.launchpad.net/bugs/571286 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
