From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daimrod Subject: Re: org-contacts development Date: Sun, 25 May 2014 01:51:11 +0900 Message-ID: <87ioovf7cw.fsf@tanger.home> References: <8761kxnno5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoFAN-0007im-LK for emacs-orgmode@gnu.org; Sat, 24 May 2014 12:51:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WoFAE-0001fC-Io for emacs-orgmode@gnu.org; Sat, 24 May 2014 12:51:27 -0400 Received: from mail-pb0-x230.google.com ([2607:f8b0:400e:c01::230]:48328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoFAE-0001eR-BJ for emacs-orgmode@gnu.org; Sat, 24 May 2014 12:51:18 -0400 Received: by mail-pb0-f48.google.com with SMTP id rr13so5567054pbb.7 for ; Sat, 24 May 2014 09:51:16 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Alexis 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