emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Neil Jerram <neiljerram@gmail.com>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>,
	Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: exported contacts problem
Date: Sat, 3 Aug 2019 20:25:37 +0200	[thread overview]
Message-ID: <20190803182537.GB23820@protected.rcdrun.com> (raw)
In-Reply-To: <CAKuG=vtL2NgokmOU6EMpOzQ5dL2QH3BW8yANaYhJ7BR8RmOihw@mail.gmail.com>

* Neil Jerram <neiljerram@gmail.com> [2019-08-03 19:49]:
> I've tried to work on contact conversion and synchronization in the past,
> aiming to merge and unify contacts that I've built up in BBDB, Google
> Contacts, email systems, pre-Android phones, etc.  The problematic aspect
> was different systems using different field names and structures, e.g. one
> with separate First Name and Last Name, and another with a combined Name
> field; different approaches to breaking up addresses; additional arbitrary
> notes fields; etc.
> 
> With that in mind, I'm curious if the writers on this thread could comment
> on:
> 1. is this situation any better now?
> 2. if you favour using org-contacts or org-vcard, what do you see as the
> benefit of Org as your master contact format, as opposed to say BBDB or
> .vcf?

Org mode is for writing hierarchically structured documents. It could
hold contacts to certain degree. Why not.

I have started keeping my contacts as bunch of business cards or paper
notes. Sooner or later it converted to the box of paper notes,
something similar as on this picture:
https://img0.etsystatic.com/000/0/5326108/il_fullxfull.298169988.jpg

Then I figured out, it is easier searchable if I keep it in text
files. That is basic system.

You could use file system hierarchy and create directory names by
groups, organizations, lists or companies.

Within each of them you could create directories by persons.

Within each directory there could be address or contact information.

Or everything in one file? That is also possible.

But the more I think about it, relational databases such as PostgreSQL
are the right tool for that. They offer all kinds of reporting,
discovery of information, all kinds of interfaces can access such
databases.

For me there is no special benefit to keep contacts in the Org
file. It is just one file, part of file system. I keep contacts in the
database and set of principle decides where is the Org file to be
found for particular person.

If person's ID is 1234, maybe such file could be found within file
system as:

~/Work/RCD/Groups/Organization-ABC/1234/1234.org

And that is the main Org file for the person. Such directory is
created automatically, I don't work on that, Emacs Lisp does it for
me.

If I create person with the ID 1234 in the database, I can click and
open Org file for the person, without knowing what is exactly the ID
of that person, or where such file is located exactly. Computer
program creates the ID, and decides where the file is placed, Emacs is
opening it for me. No thinking.

If I would keep all contacts in one Org file, that means I would have
to do a lot of file system work manually, I would need to be careful
how do I edit fields, did I make mistake, and so on, where many such
details can be handled by the database and very little programming.

My master contact or personal information management or central files
or synonym to customer relationship management is located in the
database. And I have access through Emacs to the database.

I can access contacts from Org mode by using Babel, so that is fine. I
can link to contacts or make a report about the contact in the Org
mode, as I can use SQL Babel to draw such report from Org file.

But how do I do the same other way around? It is hard. Org was not
designed for that.

Can I use scheme programming language to make a report about contacts
from an Org file? Probably not. Org has structure but it is not a
relational database[1].

Can I use Perl or Python, or Common Lisp to take information from the
BBDB, VCF or Org file? It does not work, there are no such packages in
other languages, not yet, and it does not make sense to rely in future
on contacts in Org file unless it is really just few hundreds of
personal contacts.

Even 23 hours of marketing that I have done in East Africa brought me
over 1,300 new contacts. All such contacts arrive as subscription to
mailing list. That was in 2014. Those contacts are reading my email. I
would not be able to keep all the files and stuff quickly related to
them would I be using Org file for that.

Imagine the workflow:

- create landing page

- pay marketing

- accept the entries, encrypt it on the fly. I am not keeping
  databases on Internet, never. The LISP structure get encrypted with
  the GnuPG[2] on the fly on the server, and later I simply ssh/rsync
  it to my offline computers.

- the database entry is synced to offline computer into the offline
  database. This works automatically. If I would have 1,300 contacts
  to enter in one single day, I would spend either money for workers
  or time and efforts for careful writing of it. This way their names
  get capitalized automatically, IP address can give a clue about
  their city, country, email and/or phone is entered into database

- computer is then sending them follow up emails, SMS or schedules
  meetings or phone calls, all I need to do is to make set of
  principles and few functions to handle those principles.

- now people are writing back, right? So there is live conversation,
  some of them are sending their CVs, some of them are calling,
  writing emails. So what to do now? With the Org file if they call
  you back, you need to open the Org file, to find out what is that
  phone number, who is calling, you need to locate the entry to
  understand the background of the person. He will say that he
  received your email, but 1300 other people received it too, you
  don't know who is that without quick search of the contact.

  On my side, in the shell, I am searching as:

  $ @ Peter Luca

  where sign @ is alias for "search" which searches for particular
  contacts.

  Or within Emacs, I use Hyper-c, so much close to M-c, I can enter
  few words and see the profile of the person. If there are pictures
  somewhere, I can open pictures quickly, as such are automatically
  sorted into directories appropriate to the person. I can quickly
  open Org file for the person if I wish to take notes, or I can take
  a note into the database. I could quickly open all email
  conversations and know what is this about.

I don't know how I would be doing that with Org files.

Sometimes I hire people to work together, so I give them database
access over virtual private network, and they start calling people and
following up with them, they enter information into the database, and
such information is accessible to every person working on the
database. It is collaboration feature that every SQL database has as a
built-in.

I would not be able to do it nicely with Org file. I could delegate
parts of Org file to various people and then concatenate it together
back, but I would not have a picture really what happened. I would
have to keep track of who did what at what particular time, right? You
want to know which user did what. With text files such as Org, one
need more effort to make it right.

With the database, a trigger can be installed to record the last user
that modified certain entry of the database. Trigger can indicate at
which date/time certain entry was added or modified. It becomes easier
to track events.

Instead of using Org text files as database for contacts, I can just
recommend using database for contacts whereby the database could
contain Org files related to contacts.

Jean


Footnotes:
[1]  https://www.postgresql.org

[2]  https://www.gnupg.org

  reply	other threads:[~2019-08-03 18:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02 15:47 exported contacts problem Jude DaShiell
2019-08-02 16:00 ` Jean Louis
2019-08-02 16:02 ` Jean Louis
2019-08-02 16:06   ` Jude DaShiell
2019-08-02 21:09   ` Eric Abrahamsen
2019-08-02 21:34     ` Jean Louis
2019-08-03  0:26       ` Eric Abrahamsen
2019-08-03 10:33         ` Jean Louis
2019-08-03 15:38           ` Eric Abrahamsen
2019-08-03 16:32             ` Jean Louis
2019-08-03 17:48               ` Neil Jerram
2019-08-03 18:25                 ` Jean Louis [this message]
2019-08-03 21:32                 ` Eric Abrahamsen
2019-08-03 22:12                   ` Jean Louis
2019-08-04  1:28                   ` Tim Cross
2019-08-13 22:24                   ` David Masterson
2019-08-14 20:38                     ` Eric Abrahamsen
2019-08-16  0:07                       ` David Masterson
2019-08-03 10:48         ` Jean Louis
2019-08-02 22:19   ` John Kitchin
2019-08-02 20:33 ` Tim Cross
2019-08-02 20:57   ` Jude DaShiell
2019-08-02 21:25     ` Tim Cross
2019-08-02 21:39       ` Jean Louis
2019-08-02 22:07         ` Tim Cross
2019-08-03  8:25           ` Jean Louis
2019-08-02 21:00   ` Jean Louis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190803182537.GB23820@protected.rcdrun.com \
    --to=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=eric@ericabrahamsen.net \
    --cc=neiljerram@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).