Alexis <[email protected]> writes: > Daimrod <[email protected]> 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. :-)
Sure, but then how would we define the map? with a fixed set of rules?
with a user customizable map (e.g. '(("MOBILE" -> "TELL;CELL")
("EMAIL_WORK" -> "EMAIL;TYPE=work")))?
I'm not saying that it's impossible nor that we shouldn't do it but that
we need to think about it first. :)
>> 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.
Well, if people are willing to help, I'll see if I can come up with a
proposal.
--
Daimrod/Greg
signature.asc
Description: PGP signature
