bug-recutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-recutils] recutils and vcard


From: David J Patrick
Subject: Re: [bug-recutils] recutils and vcard
Date: Sun, 9 Dec 2012 21:31:58 -0500

On 9 December 2012 13:58, Jose E. Marchesi <address@hidden> wrote:
vcard is basically recutils plus "properties".

The vcard format allows to specify "properties" of the entries.  For
example in the vcard entry:

  tel;type=work: 123456

type=work is the definition of a property.

So we would need to add something similar to these properties to
recutils.  Do we want to do that?  And in that case, which syntax to
use?

I think the idea is not to re-invent or re-implement vcard, but to parse it as-is using recutils. It seems to me (and you) that the formats of vcard and recutils are close cousins. The two format differences I can see are a) the properties you mentioned, and b) the seemingly minor deviations, like semi-colon, instead of colon, and the lack of [space] following it.
The ideal solution, from my bad-programmers perspective, would be to build in a special, predefined record descriptor "%rec: vcard", that tells recutils that the following block, up till the next "%rec: something-else", will follow the standardized vcard file format.
That said, if a record descriptor block could adequately describe vcard records, and that could be defined with the existing tools so that it could parse, either in-line or as an external %rec descriptor, then that would be just fine.. although I suspect that it's currently out of range.
The matter of "properties" is an interesting one, too, and whether this adjunct could be extended to all of recutils, or whether it worked only with "%rec: vcard" is another interesting question, one that could only be answered by someone who had a better familiarity with the code-base.
Thanks for entertaining the idea. With this enhancement recutils could become a contact management power-house, juggling existing, unmodified vcard files, on top of it's already considerable bag-of-tricks.
djp

reply via email to

[Prev in Thread] Current Thread [Next in Thread]