[Vobject] vcard subcomponents

[Nick Guenther]

On Mon, Apr 7, 2008 at 5:53 PM, Jeffrey Harris
<jeffrey at osafoundation.org> wrote:
> Hi Nick,
>
>
>  > What I'm trying to do is turn gmail's contact cards into vCards.
>
>  Ah, OK.  Is there a reason you aren't using gmail's built in export to
>  vCard feature?  I'd be delighted to see a Python implementation that
>  turns GData contacts
>  (http://code.google.com/apis/gdata/elements.html#gdContactKind) into
>  vCards, is that what you're working on?
>

...because I didn't look around first. I assumed that because I have
to screenscrape to get out emails I'd also have to do it for
everything else in the system... also the codebase (libgmail.py)
already had a hacked in implementation for this and I did the
obvious-programmer-thing to do and went with it. Thanks for pointing
that out, though. I just tried exporting out and it's not perfect
since forces per-contact data into a tabular form, which is basically
the same reason I'm working on this in the first place: what gmail
/graciously/ allows you to get via POP/IMAP is not everything that
gmail has (namely: it's missing threading and labels); that's their
trick: get you using gmail by telling you you can always get your
email out, but then you just have to stay because your archive would
be incomprehensible if you lost that structure.
This gmail contacts data API seems to be.. similar. I don't see
anywhere that the extra fields in gmail could go.

Anyway, to the point: Perhaps reformatting this as vCard is not worth
the effort, though. Not for the library, anyway.

>  > A gmail contact has a name, an email address, a multiline note, and
>  > then a list of extra contact information which is a name ("Personal",
>  >  "Work" etc) and then pairs (type, value) where type is like 'email',
>  >  'phone', 'IM' etc. and value is just some single line. I figured I
>  > would use a subcomponent for each set of extra things. The way I
>  > originally wrote the code (with with having c.add('personal').value =
>  >  subcomponent) was because I figured each subsection is named, and
>  > then has subpieces.
>  >
>  > How would you all arrange this? Am I using vCards right or do I have
>  > some misconception about them?
>
>  Many, though not all, of these things map naturally to a vCard
>  content-line, in these cases I don't think you want a custom
>  sub-component.  Generally speaking, I think it's worth mapping to
>  "standard" vCard content-lines whenever possible, because it's then
>  possible for other implementations to read the card.
>
>  The problem with custom sub-components is that no application (other
>  than your own) is likely to read them.  That's why this problem with
>  custom subcomponent hadn't come to my attention yet; I don't use them :)
>
>  Of course, it's a lot more work to map fields based on your
>  understanding of what's intended.  My suggestions might be more accurate
>  if I knew in more detail what you're hoping to achieve.


I agree, I do want to fit this into other standards as much as
possible, but my first goal is to extract data losslessly. Now, in
practice it's probably not a huge deal because I don't know of anyone
who anally fills in all the details on their gmail contact cards, but
I try to make a point of coding to correctness first, usefulness on
top of that.

 But what do you mean by content line? The gmail data structure is
arranged so that there are these blocks of data (that you can each
give a (non-unique) name, the idea being that some will be personal,
others will be for work, but that you're not restricted to that) that
each contain multiple (non-unique) fields. as far as I can see there
is no way to flatten this out without losing that structure.


-Nick