emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: "Sébastien Rey-Coyrehourcq" <sebastien.rey-coyrehourcq@univ-rouen.fr>
Cc: Alan Schmitt <alan.schmitt@polytechnique.org>,
	emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: SQLite for contacts and relations to Org - Re: contact management in emacs
Date: Tue, 11 Oct 2022 22:59:51 +0300	[thread overview]
Message-ID: <Y0XLN1Wu8iEQaqv4@protected.localdomain> (raw)
In-Reply-To: <87mta26h0s.fsf@univ-rouen.fr>

* Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> [2022-10-11 08:56]:
> Hi Jean Louis,
> 
> First i want to thank you for this very detailled explanation, this is very valuable for someone that start in elisp like me.
> 
> Secondly, i found the idea of using sqlite for contacts very interesting, and i think a lot on this solution on my side the last weeks. With the new emacs interface to sql, it was easy i suppose to create a “both-way” syncing tool between org-contact (to easily maintain info, linking to notes, agenda, etc.) and a database that anyone could reuse, move, send also using mobile phone.
> 
> I use org-roam that use both of the two world, database and org, in the light of recent discussion, why we cannot do the same things for org-contact ? Linking / syncing properties with unique hash/id also stored in a database. If you have 150000 contact, with 150000 unique ID, and if you want to create an org-contact file/propertie into an org document, that’s probably easy to inject and maintain some sort of syncing (like org-roam do) between the info in database and the info into some properties block no ?

That is exactly the point. Why keep well structured information such
as phone numbers, emails, addresses, in Org file, when structured
information by its type belong into structured forms like databases.

Keeping it in Org or any text files is not scalable, not usable, not
shareable. To tell people to use text files to keep information is
detrimental for people who listen to it. They can't know it
immediately, but one day they will realize that it does not fly.

Why email clients like Thunderbird have contacts features built-in?
For reason that contacts are related to communication and
information. Communication is connection in every relation between
people. Information is written because it fosters communication and
thus relations.

Org contacts try to store contacts into Org file. I don't know the
rest. I have looked inside the Org contacts code and I do not agree
with the design. It is not scalable.

From code:

,----
| To enter new contacts, you can use `org-capture' and a minimal
| template just like..
`----

;; this:

;;         ("c" "Contacts" entry (file "~/Org/contacts.org")
;;          "* %(org-contacts-template-name)
;; :PROPERTIES:
;; :EMAIL: %(org-contacts-template-email)
;; :END:")))
;;
;; You can also use a complex template, for example:
;;
;;         ("c" "Contacts" entry (file "~/Org/contacts.org")
;;          "* %(org-contacts-template-name)
;; :PROPERTIES:
;; :EMAIL: %(org-contacts-template-email)
;; :PHONE:
;; :ALIAS:
;; :NICKNAME:
;; :IGNORE:
;; :ICON:
;; :NOTE:
;; :ADDRESS:
;; :BIRTHDAY:
;; :END:")))

;;;; Usage:

;; How to search?
;; - You can use [M-x org-contacts] command to search.

I would not bother using that. Why? Because of experience.

- many people have many various emails, not just one. 

- by using email as reference, I quickly jump to list of conversations
  with that person

- if email is invalid, I still need the conversation retained

- I must know if email is for work or private, it needs more structure

- phones, I am sending SMS, I must know in structured way, if the
  phone belongs to provider ABC or XYZ, as that decides on routing on
  how to send SMS messages. Nobody likes spending money by using wrong
  providers. 

- fax is phone line, mobile phone and fixed lines are not same, I must
  know type of phone line;

- aliases and nicknames belong to identities,

- single note about contact is not enough, contact may be related to
  many notes.

- address must be structured, otherwise it is really difficult to use
  it programmatically:

                             ID   198333
                   Date created   "2022-10-11 21:28:42.565176"
                  Date modified   nil
                   User created   "maddox"
                  User modified   "maddox"
                         Person   "Joe Doe"
                           Type   "Default address"
                   Address Name   "Address in Germany"
                        Line #1   ""
                        Line #2   ""
                        Line #3   ""
                           City   ""
                         Region   ""
                      Post code   ""
                        Country   "GERMANY"
                 Date validated   nil
                       Location   nil
                    Description   nil
                       Inactive   nil
                        Default   nil

There is no option but to keep structured information in structured
databases. I have working system with PostgreSQL and decentralized
collaboration, but I am now making SQLite minimized version, so when
package is finished I will let you know.

Package preparation:
https://gnu.support/images/2022/10/2022-10-11/Screenshot-2022-10-11-22-50-03-955596051.png

Editing of entry:
https://gnu.support/images/2022/10/2022-10-11/Screenshot-2022-10-11-22-57-51-793932307.png


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/


      reply	other threads:[~2022-10-11 20:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-27 11:08 contact management in emacs Alan Schmitt
2021-02-27 11:31 ` Martin Steffen
2021-02-27 13:20   ` andrés ramírez
2021-02-27 14:40     ` Eric S Fraga
2021-02-27 15:12       ` andrés ramírez
2021-02-28 10:21         ` Eric S Fraga
2021-02-27 15:14       ` Martin Steffen
2021-02-27 17:00   ` Dr. Arne Babenhauserheide
2021-02-27 16:53 ` Bob Newell
2021-02-28  9:06 ` Russell Adams
2021-02-28 11:09   ` Alan Schmitt
2021-03-03 14:40   ` TRS-80
2021-03-07 22:57   ` Jean Louis
2021-03-08 20:06     ` John Kitchin
2021-03-10  8:32       ` Jean Louis
2021-03-07 22:13 ` Jean Louis
2021-03-08  7:49   ` Alan Schmitt
2021-03-08  8:12     ` Jose E. Marchesi
2021-03-10  8:32       ` Jean Louis
2022-09-09 16:11 ` Sébastien Rey-Coyrehourcq
2022-09-10  5:46   ` Ihor Radchenko
2022-10-09 10:40   ` SQLite for contacts and relations to Org - " Jean Louis
2022-10-09 15:21     ` Quiliro Ordóñez
2022-10-09 16:59       ` Jean Louis
2022-10-09 19:09         ` Quiliro Ordóñez
2022-10-10  6:12           ` Jean Louis
2022-10-10 22:29             ` Robert Weiner
2022-10-10 23:32               ` Jean Louis
2022-10-11  3:20                 ` Robert Weiner
2022-10-11  5:54     ` Sébastien Rey-Coyrehourcq
2022-10-11 19:59       ` Jean Louis [this message]

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=Y0XLN1Wu8iEQaqv4@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=alan.schmitt@polytechnique.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=sebastien.rey-coyrehourcq@univ-rouen.fr \
    /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).