Hello! I only saw this email now - please copy me directly on emails that you want me to see.
On Fri, 2013-05-17 at 15:34 +0200, Milan Crha wrote: > Hello all, > there was a little discussion about vCard 4.0, aka [RFC6350], which > adds, among other things, a valuable KIND attribute, which is used to > differentiate what the vCard is for. That would get rid of the > evolution's X-EVOLUTION-LIST attribute, and maybe more. Here's a list of > changes between 3.0 and 4.0 vCard [2]. The RFC is not that old yet, it's > only from August 2011, but I guess it's not a problem. > > I'd like to know from others their opinion, whether it would be > appreciated to switch to vCard 4.0 by default in evolution > (-data-server). The plan is to keep backward compatibility with 3.0, > even be able to save in 3.0 format (probably by some combo in a save > dialog to pick the format user prefers), but otherwise switch internally > into vCard 4.0. That way specialized editors could be created (as you > know, there are currently only two, one for general contact, the other > for contact list; maybe it'll make sense to introduce new contact editor > for organization, room, and so on). In general I consider that a good thing. vCard 4.0 is a step forward, but it is not going to be adapted unless someone starts. But being the first to move forward will also mean that there will be problems exchanging data with peers that are still on vCard 3.0, simply because some information cannot be stored there. This is nothing new and SyncEvolution is prepared for such kind of format mismatches, it just will be some work to adapt it. In Evolution it would be good to have the ability to mark an address book as "only supports vCard 3.0 properties". Such a flag should disable all UI features which rely on vCard 4.0. Then address books which mirror a remote vCard 3.0 address book will be usable without surprises for the user. > I also do not know how will other programs work, when user would try to > import a 4.0 vCard, while the program only knows 3.0. I believe the > reading should not be strict on versions, the version only gives a > "hint" what the card can, and what it should not, contain, right? One would hope so, but there's nothing in the standard requiring that. A client might also decide to play it safe and reject vCard 4.0 because it simply cannot know whether the vCard 3.0 decoding rules still apply. For example, in an early draft of vCard 4.0 the set of characters which needed quoting was defined differently than in 3.0. This was reverted back to the rules from 3.0 later on to enhance backward compatibility, but it might as well have stayed in the spec. -- Bye, Patrick Ohly -- [email protected] http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
