Re: org-contacts development

[Daimrod <daimrod@gmail.com>]

Alexis <flexibeast@gmail.com> writes:

> Hi all,
Hi,

> [snip...]
>
> Fleshing out an extended spec for org-contacts data could be part of the
> process of making org-contacts a first-class citizen of org-mode, and
> provide a more solid foundation on which people can build (and share)
> the org-contacts functionality they're after. And in my own particular
> case, it would greatly facilitate my work in org-contacts / Android
> Contacts integration. :-)
>
> What do people think?

IMHO, the "problem" with org-contacts isn't that it isn't part of
org-mode, but that its format isn't well defined enough.

Some fields accept only one value, some multiple values, with different
separators, etc... And on top of that, there is no easy way to access
the database (`car', `cadr', `caddr', ...) which makes it difficult to
read and write code.


So, as you said, we would need to define and document a specification
for org-contacts. And we need to be clear from the beginning about
what it can do and what it can not do. For example, it is unlikely
that org-contacts will be a 1:1 mapping with the vCard format in its
current form because vCard properties can have values.

e.g.
PROP1;PROP2=VAL:FOO BAR
      ^^^^^^^^^

And AFAIK we can't do that with org-mode properties.

An approach would be to keep using properties whenever it's possible
to keep the format simple when possible and use subtree instead of
properties when necessary.

e.g.
#+BEGIN_SRC org
  ,* Contact Name
  ,** PHONE
     :PROPERTIES:
     :TYPE:     WORK
     :END:
  - num1
  - num2
#+END_SRC

But then we would need a special property to indicate that a subtree
is a contact and ignore subtree without this property (just like it
does with the EMAIL property ATM).

#+BEGIN_SRC org
  ,* Contact Name
    :PROPERTIES:
    :TYPE:     org-contacts
    :END:

  ,** PHONE
     :PROPERTIES:
     :TYPE:     WORK
     :END:
  - num1
  - num2
#+END_SRC

And of course it would be nice if we could keep as much compatibility
with the current format :)

-- 
Daimrod/Greg