From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WLVXCRLSRWOwXAEAbAwnHQ (envelope-from ) for ; Tue, 11 Oct 2022 22:29:06 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id cCF1CBLSRWNPUAAAG6o9tA (envelope-from ) for ; Tue, 11 Oct 2022 22:29:06 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3574D24DAD for ; Tue, 11 Oct 2022 22:25:15 +0200 (CEST) Received: from localhost ([::1]:57810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiLoP-0003ED-M3 for larch@yhetil.org; Tue, 11 Oct 2022 16:25:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiLWP-0006TH-IF for emacs-orgmode@gnu.org; Tue, 11 Oct 2022 16:06:38 -0400 Received: from stw1.rcdrun.com ([217.170.207.13]:33927) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiLWL-0003hK-BY for emacs-orgmode@gnu.org; Tue, 11 Oct 2022 16:06:37 -0400 Received: from localhost ([::ffff:197.239.5.209]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000BBD14.000000006345CC9E.000059BD; Tue, 11 Oct 2022 13:05:49 -0700 Date: Tue, 11 Oct 2022 22:59:51 +0300 From: Jean Louis To: =?utf-8?Q?S=C3=A9bastien?= Rey-Coyrehourcq Cc: Alan Schmitt , emacs-orgmode Subject: Re: SQLite for contacts and relations to Org - Re: contact management in emacs Message-ID: Mail-Followup-To: =?utf-8?Q?S=C3=A9bastien?= Rey-Coyrehourcq , Alan Schmitt , emacs-orgmode References: <87lfb9bwff.fsf@m4x.org> <090c6ca8-62e1-edcd-d348-688281c4840d@univ-rouen.fr> <87mta26h0s.fsf@univ-rouen.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mta26h0s.fsf@univ-rouen.fr> User-Agent: Mutt/2.2.7+37 (a90f69b) (2022-09-02) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, FILL_THIS_FORM=0.001, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1665519915; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=97Z/Xfa6WbUlHdO9B3Pkz9FQNlvoizOW9EyAezeA/mU=; b=TVxKXQGtAXadwK7dNY2SpKP4EfblwR1iH/EnyOxxvXgtJtnFRXv7DKe59nYT1Br3CU2VHm h/D3UmQQ0+kOGdEuxPuRYShiIla2EwdGiXCSpli8JdBeAG/a2XpRKzOCVPzEgUcVqOD+P9 QT0D0tvqL90foVIRvlmnfVcTKj4ne0jVBhOVLkuYRNdo5a3QijiHWbJeoIQXtT+5zScxkK M2xahlbQa6AE+HuZWKPisCPae3wo8BQEkABpAjkbaJgDQbAyw3UOca8NLx0z5SmDXLgFYm JROK14X/HhfWnjc2mnUQJVl89XfB75bDJ8dZWsoTYhEMN+DYR89oxZhITp8l6Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665519915; a=rsa-sha256; cv=none; b=Cx8tW76WuZ/Uwu9eVTBRbNuZRGMyLHARSkq+fSz7zF1BRwZoV6qJprfXGpFCwMxfrWncXC r7Urxw9enP6I/mod3YE2iVmkG8fq8qZYxVhhq24I3IQJ/QNRKdGeuzeZnVS9Xa6cUNbvCu JkY4GlYncHIdtnKSWtemyfBZYIm/T1JaCr7OUW2xU31T/qyUcBlgwsVGEPYoEY2s7gDcjW XQyUzNybi1TomLlcAdK9/Kxtb+Dsb3K+HQl6REv2f7LStRvUpJK7Ej+34Gjpc6s+d3cnyE 08uRtrN2Y2uMhKOhJf02h6DUwGhJOaiVToYqJaD5G13atVHcY5EF2AjlYmreYQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.39 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3574D24DAD X-Spam-Score: -1.39 X-Migadu-Scanner: scn1.migadu.com X-TUID: /5xsUnfXs2GD * Sébastien Rey-Coyrehourcq [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/