emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* org-contacts to vCard
@ 2014-07-05 10:28 Alexis
  2014-07-07  5:42 ` Feng Shu
  0 siblings, 1 reply; 2+ messages in thread
From: Alexis @ 2014-07-05 10:28 UTC (permalink / raw)
  To: emacs-orgmode


Hi all,

i recently posted about connecting `org-contacts` with MobileOrg:

(1) https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg00971.html

Part of the resulting thread was about fleshing out an 'official' spec
for the org-contacts format. Another part was about using DAV as part of
a putative syncing process.

This has led me to start working on an `org-carddav` package[*], à la
the existing `org-caldav` package (regardless of whether a DAV-based
approach ends up being used for syncing between `org-contacts` and
MobileOrg); this in turn has led me to start working on an `org-vcard`
package. Which brings me back to the issue of the org-contacts format.

The most recent post on this topic that i can find is:

(2) https://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00140.html

Taking into consideration people's comments on this matter in thread
(1), i'd like to propose the following:

--

Define a property `ORG_CONTACTS_STYLE`. The default value is 'flat', and
represents the way org-contacts currently works:

,* People
,** Alexis
,:PROPERTIES:
,:CELL: 0000 999 999
,:PHONE: 00 9999 9999 
,:EMAIL: address.1@example.com
,:END:

A second value `ORG_CONTACTS_STYLE` can have is 'tree':

,* People
,** Alexis
,:PROPERTIES:
,:KIND: individual 
,:FIELDTYPE: name
,:END:
,*** Landline
,:PROPERTIES:
,:FIELDTYPE: landline
,:END:
,**** 00 9999 9999
,*** Mobile
,:PROPERTIES:
,:FIELDTYPE: mobile
,:END:
,**** 0000 999 999
,*** Email 1
,:PROPERTIES:
,:PREFERRED: 
,:FIELDTYPE: email
,:END:
,**** address.1@example.com
,*** Email 2
,:PROPERTIES:
,:FIELDTYPE: email
,:END:
,**** address.2@example.com

For each value of ORG_CONTACTS_STYLE, define a default mapping:

,#+ORG_CONTACTS_STYLE: flat

,+----------------------------------+-------------+
,| PROPERTIES field                 | vCard field |
,+----------------------------------+-------------+
,| [ heading with 'KIND' property ] | FN          |
,| CELL                             | TEL;CELL    |
,| MOBILE                           | TEL;CELL    |
,| LANDLINE                         | TEL;HOME    |
,| PHONE                            | TEL         |
,| EMAIL                            | EMAIL       |
,| ...                              | ...         |

,#+ORG_CONTACTS_STYLE: tree

,+------------------+-------------+
,| FIELDTYPE field  | vCard field |
,+------------------+-------------+
,| name             | FN          |
,| cell             | TEL;CELL    |
,| mobile           | TEL;CELL    |
,| landline         | TEL;HOME    |
,| phone            | TEL         |
,| email            | EMAIL       |
,| ...              | ...         |


Users would be able to change and extend the above mappings as works
best for them. And of course, there's potential to define entirely new
mappings.

`org-vcard` would then be able to export org-contacts to vCard depending
on the value of ORG_CONTACTS_STYLE. And since the default value of this
property would be 'flat', backwards-compatibility would be preserved.

--

The reason i'm proposing a new contacts style of 'tree' is to create one
that more takes advantage of Org being an outliner. Rather than having a
huge flat property list with no ability to show/hide relevant groups, it
seems to me to make sense to be able to do something like:

,* People
,** Alexis
,*** Work
,**** Phone
,**** Email
,*** Home
,**** Phone
,**** Email
,* Organisations
,** Acme
,*** Coyote Services
,**** Anvils
,***** Phone
,***** Email
,**** Rope
,*** Snake Oils

and be able to show/hide the relevant sections as required.

Further, i believe the mappings approach avoids having to make fixed and
final decisions which everyone has to agree on - different people will
have different needs in different use-cases. And inserting new contact
data could be facilitated via an interactive function which does a
`completing-read` using the values of the first column in the
currently-active mapping table, then creating the relevant PROPERTIES
drawer with the appropriate value(s).

Finally: yes, i am personally willing to do all the coding to support
this proposal. :-)

What do people think?


Alexis.

--

[*] Though i'm already encountering the same possible issue with the
`url-dav` package that i've found when trying to use `org-caldav` with
a DAViCal server:

https://github.com/dengste/org-caldav/issues/45

Is anyone successfully using `org-caldav` (or `url-dav`) with a DAViCal
server?

^ permalink raw reply	[flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-07-07  5:57 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-05 10:28 org-contacts to vCard Alexis
2014-07-07  5:42 ` Feng Shu

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).