[Vpim-talk] editing and deleting fields in a vcard

Sam Roberts sroberts at uniserve.com
Wed Mar 1 15:04:26 EST 2006

> Thanks for your reply. I think it would be useful to be able to edit a vcard
> in place rather than having to copy all the fields into  a new vcard. I
> wouldn't worry about the user nuking their vcards - I think it should be up
> to the user to make sure the edited vcard is valid. I think you can already
> mess up a vcard anyway by using push to append a field to a vcard if that
> field already exists.

True, though I've called that a bug and fixed it in my working copy
(can't add BEGIN/END/VERSION, can't add N or FN if they are already
there, everything else is allowed multiples).

I also added copying examples, and higher level APIs to copy kindof
based on what I described below. I've some more hours of work before its
cleaned up for release, though, the unit tests are broken.

And I'll try and come up with an API to make Vcard mutable in some way
that is moderately safe. It won't be in the next release, though, I've a
day job. :-)

> Another issue related to editing is the ability to save a vcard in
> different formats. For example, if I edit a vcard that is vcard-2.1,
> vpim will save the new vcard as vcard-3.0 format. It would be useful
> to be able to specify vcard2.1 format, or have a method for outputing
> the vcard as a string  in 2.1 format.

One of the design goals of vPim is to NOT modify input data if possible
when rewriting, so this is definitely a problem.

I'll also try and make round-trip work 1-to-1, and make it faster
(profiling makes it look like performance is dominated by String#upcase
and String#downcase, believe it or not).

The encoding variables are:
 - VCARD version (2.1/3.0), which mostly affects how params are
   specified, and the allowed encodings and names of those encodings.
 - character set

Currently, decoding auto detects utf-8 and ucs-2, with or without byte
order marks, but always writes as utf-8 without BOM. It would be nice to
control this.

I've two possible approaches:

 - make these options part of the Vcard, so changing the version would
   involve mutating the vCard or copying a vCard to a new one that is
   set to a different version

 - make them an input to the encoding process, where the default is the
   values stored in Vcard when it was decoded.
Have you ever wanted to encode the same card in multiple character sets,
or multiple vCard versions? If that is common, I need to make it part of
the encoding process, otherwise I can make it part of the Vcard, which
is easier


More information about the Vpim-talk mailing list