Re: [VCARDDAV] VCARDDAV Digest, Vol 12, Issue 45

From: vcarddav-bounces at ietf.org [mailto:vcarddav-bounces at ietf.org] On Behalf Of Jean-Luc Schellens
Sent: Wednesday, August 06, 2008 5:28 PM
To: vcarddav at ietf.org
Subject: Re: [VCARDDAV] VCARDDAV Digest, Vol 12, Issue 45

…

I believe I see what you are trying to do, but there are several problems.
1) If you really want to track when each change that has occurred to the
vCard was done, then you probably want to do it for all properties, not just
the multi-valued ones with PIDs (e.g. when was the UID created, or last
changed).
2) Size, Size, and more Size.... That can get pretty big, and how realistic
is it for that data to actually be kept? The majority of portable devices
(other than laptops :-) ) still send vCard 2.1, instead of vCard 3.0, and
almost all of them only deal with vCal - almost none accept iCal. They are
pretty slow to change, use extra memory, etc.. You really are talking more
about Journaling at this point, such as vJournal or something else. If it
helped for a significant set of cases, that would be one thing, but
virtually all syncs today would have one side toss that data out, so the
data would never be used.
3) Sync Conflicts. If I am merging two parallel sets of changes what
date/time matters? If I use the original time that something changed
somewhere else, that will have sync problems, because it has changed in my
copy of the vCard since that time, so I need to send that change out to
everyone else I sync with. But if I use the time of the merge, then either
I will be out of sync with the other side (I say it changed when I
incorporated the value into my vCard, while the other side still has the
original change time), or else I send my time of change back to the other
side, and it will have redundant changes being sent out - the date of change
is different, but the data isn't.
4) Details.

…
Anyway, to me #2 is a killer - I just don't see where implementations would
actually be able to use it for anything in the real world. It would be
great if the data was available, but it seems more just a good theory, not
actually practical.

I understand your reactions but let's take into account:

1 - Which vCards are frequently updated (add/edit/delete).

- Your own cards - how many do you have? I have more than 10 personal/professional cards because I'm a consultant working for different companies as a self-employed collaborator, but I think I'm quite an exception! Anyway, I'm not updating frequently my own cards!

- The cards of your contacts - how many do you have? I have currently more than 250 (family, friends, colleagues...).

For me, 1 – I create custom ones when I need to. However, I have gone through 9 companies, several with more than one address, each with different email addresses and office and mobile phone numbers, at least 4 ISPs with their addresses (although I keep just one email forwarder), and so on. It does start to add up, which leads to wanting to truncate it at some point, which allows people to truncate it really short and then its no longer useful…

955, but I have been getting lazy and not entering lots of them in the last couple of years – just searching for people’s emails when I need to – basically using search instead of the address book most of the time. Most only get updated every couple of years, when I hear that someone has switched companies, has a new email address, birth/marriage/child, phone number, etc.

You especially have to watch out for the CEO or Sales executive with 10K+ contacts, when they go to demo the product…

But I rarely update these cards! In fact, I'm expecting updates from my contacts. That's why the Plaxo concept of "update requests" was great (but poorly implemented/marketed)!

And if you look to Facebook, having more than 500 "friends" is quite a "non-sense record" ;o))

So for me size it's no a real concern, even if all the properties will have a PID.

When you create a vCard, you'll have REV:PID=ALL;TYPE=created;2008-08-08

When you update a vCard, you'll have REV:PID=2;TYPE=deleted;2008-10-10

When you delete, you'll have REV:PID=ALL;TYPE=deleted;2008-10-12.

+/- 100k to compare with a KEY (+/- 2800k) or a PHOTO/LOGO

2 - It's not because vCard 2.1 and mobile platforms are limited today that we have to restrict vCard 4.0. We have to target the "smartphones" which will becomes commodities in the next 5 years. (With guys from Apple, Cisco, Nokia, Oracle, Qualcom, Samsung, Sun... in the vcarddav group ;o))

I think you miss the point I am trying to make – I was referencing what Smartphone’s and PC’s do, not just low end devices. It’s not just something that goes away when they have more than X Kb/Mb/Gb. Microsoft Outlook (at least through 2003 – I can’t bring myself to try a newer version) can only export vCard 2.1, for example – a PC application. It isn’t because of limited memory – it’s on a Windows platform, and uses huge amounts of memory.

Anyway, nearly all devices and environments end up with the Sync Application separate from the Address Book Application. Nearly all Address Book Applications end up storing the data in their own internal format (usually some kind of relatively static structure), not as a vCard. All the data that does not exactly fit into that static format ends up having to be stored in the Sync Application, separate from the address book. When the vCard is a good fit with the address book, then most of the data can go in the address book, with just a little bit in the Sync Application. Things that aren’t a good fit have to have special processing by the sync app, and the path of least resistance for a lot of developers is to throw away data they don’t need for anything….

In that case, a 100K photo that has a home in the parent application has almost no cost if you aren’t bandwidth limited, while PIDs and REVs and UIDs and so on do have costs.

If you are bandwidth limited (including due to cost while roaming), then large photos (etc) shouldn’t be transferred – only the things actually usable on that device. Because the developer of the handset app works for the company that gets screamed at when it takes several hours to do the initial sync of their address book, or causes the infamous multi-thousand dollar roaming bills, it is an environment where it is highly desirable to be as conservative as possible. Essentially, if there isn’t an obvious immediate advantage to them storing or transferring the data, they probably won’t. I’m just rather pessimistic about storing extra data, or making extra changes, because I have been banging my head against that brick wall for over 11 years now. We have a lot more memory now, and a lot more data, but there still is the desire to keep it to only what is critically needed. Maybe when 4G, or 5G, etc. comes out, or when all plans have free data roaming over entire continents, but we are many years past what I first thought the limits were…

Anyway, it all comes down to what opinions people hold about what is a “reasonable” amount of extra data, which is going to vary.

3 - For me vCard 4.0 is a great opportunity to relaunch the electronic exchange of personal data and to be definitely rid of the paper business cards. (For me the business card reader is one of the most stupid product but its success is probably due to the limits of vCard. And I also hate the email's automatic signature with all the sender data at the bottom when you know how simple it's to attached a vCard to the signature!)

I agree about paper cards, but don’t forget how many people in the IETF still prefer to stick with only plain-text email – any attachments, especially repeated on each email ones, are seen as evil and annoying by some people.

4 - So to conclude, such a rich REV property will be a great solution for all the data quality and synchronization issues which are today real nightmares as you probably know

Regards

Jean-Luc