From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexis Subject: Re: org-contacts development Date: Sun, 25 May 2014 03:48:00 +1000 Message-ID: <87fvjzgjan.fsf@gmail.com> References: <8761kxnno5.fsf@gmail.com> <87ioovf7cw.fsf@tanger.home> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoG3H-0003XQ-KI for emacs-orgmode@gnu.org; Sat, 24 May 2014 13:48:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WoG3C-0000z4-6J for emacs-orgmode@gnu.org; Sat, 24 May 2014 13:48:11 -0400 Received: from mail-pb0-x22d.google.com ([2607:f8b0:400e:c01::22d]:44284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoG3B-0000yr-VD for emacs-orgmode@gnu.org; Sat, 24 May 2014 13:48:06 -0400 Received: by mail-pb0-f45.google.com with SMTP id um1so5635813pbc.32 for ; Sat, 24 May 2014 10:48:04 -0700 (PDT) Received: from localhost (ppp118-209-145-187.lns20.mel6.internode.on.net. [118.209.145.187]) by mx.google.com with ESMTPSA id wn6sm31849194pab.18.2014.05.24.10.48.02 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 24 May 2014 10:48:04 -0700 (PDT) In-reply-to: <87ioovf7cw.fsf@tanger.home> 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 Daimrod writes: > 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 > ^^^^^^^^^ Agreed. But it seem to me we could at least map e.g. "TEL;CELL:" (which is how my Android phone vCard-exports a mobile number) to e.g. ":MOBILE:" or ":PHONE_CELL:". And we could map things like e.g. "EMAIL;TYPE=work:" to e.g. ":EMAIL_WORK:". This is just brainstorming, however. :-) > 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 :) Well, to me this looks broadly similar to what Esben has proposed: https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html Although i like the idea of such a format in principle, my concern (as i noted in my reply to Esben) is that this might require a substantial modification of org-contacts.el, both to accommodate this format and to ensure backwards-compatibility. If this is indeed the case, and someone else is willing to commit to being the lead on undertaking that work, then i'll certainly support that work and write relevant MobileOrg code to work with both the new and old formats. Otherwise, from my perspective of wanting to simply add some more fields and be able to transfer contact details between MobileOrg and my phone's Contacts system, it's more than i'm willing to take on at this point. Alexis.