Jonathan Bernard
daa58518e3
- Unify the naming pattern of types and enums. Specifically:
- use `VC_Param` instead of `VCParam`. The goal here is to make the
important information (Param, Source, PropertyName, etc.) easy to
see at a glance while preserving a prefix that allows multiple
implementation to coexist (VC3_Source vs. VC4_Source) and also be
easily distinguishable at a glance.
- use `pnName` instead of `cnName`. The VCard standard refers to each
line of data as a "content line," so the original name of each was
"Content." However, the spec more commonly refers to each piece of
data as a "property." There is a 1-to-1 mapping of content lines to
property instances, but property is a more accurate name.
- Introduce the idea of property cardinality to the VCard3
implementation. The spec does not tightly define property cardinality,
but implies it with statements like "if the NAME type is present, then
*its* value is *the* displayable, presentation text associated..."
(emphasis added). Similar language implies some properties must be
present exactly once (FN, N, VERSION) or at most once (NAME, PROFILE,
SOURCE, BDAY, CATEGORIES, PRODID, REV, SORT-STRING, UID). Any other
properties are assumed to be allowed any number of times (including
0).
In the case of a VCard that contains multiple instances of properties
expected to be singular, the parser will still parse and store these
properties. They can be accessed via the `vcard#allPropsOfType`
function. For example:
# vc3 is a VCard3
allPropsOfType[VC3_N](vc3)
If we see over the course of time that other implementations regularly
use multiple instances of properties we have expected to be singular,
we are open to changing the contract to treat them so (though this
may be a breaking change).
- Refactor the VCard3 implementation to use generated property
accessors, following a similar pattern to the new VCard4
implementation.
- Remove the accessor definitions that allow access via the content seq
directly (`vc3.content.name` for example). There really isn't a reason
for this use-case and the library is simpler without exposing this.
VCard
nim-vcard is a pure nim implementation of the VCard format defined in RFCs
2425, 2426, and 6350. It allows you to parse and serialize VCards, as well as
create VCards programmatically. It aims to be a complete implememtation,
supporting all of the features of the VCard3 standard. Because the standard
provides many features that may be rarely used, this library also provides a
simplified API for more typical use-cases.
Example Usage
BEGIN:VCARD
VERSION:3.0
UID: 5db6f100-e2d6-4e8d-951f-d920586bc069
N:Foster;Jack;Allen;;
FN:Allen Foster
REV:20230408T122102Z
EMAIL;TYPE=home;TYPE=pref:allen@fosters.test
EMAIL;TYPE=work:jack.foster@company.test
TEL;TYPE=CELL:+1 (555) 123-4567
END:VCARD
4839ff64a8/examples/simple.nim (L1-L22)
Future Goals
- VCard 4.0 support
Debugging
Need to clean up and organize
Run tvcard3 tests in gdb:
$ cd tests
$ nim --debuginfo --linedir:on c tvcard3
$ gdb --tui tvcard3