From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: persistent data feature Date: Sat, 11 Dec 2021 20:36:29 +0100 Message-ID: <875yrvgchu.fsf@logand.com> References: <87tufmjyai.fsf@gnus.org> <87bl1olyhr.fsf@localhost> <87bl1ngnj1.fsf@logand.com> <3437406.lxAJRBJNBK@galex-713.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26449"; mail-complaints-to="usenet@ciao.gmane.io" To: Alexandre Garreau , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 11 20:54:23 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mw8Rq-0006di-Vq for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Dec 2021 20:54:22 +0100 Original-Received: from localhost ([::1]:40510 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mw8Rp-0004Gw-UV for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Dec 2021 14:54:21 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw8Ae-0004Z9-KZ for emacs-devel@gnu.org; Sat, 11 Dec 2021 14:36:36 -0500 Original-Received: from logand.com ([37.48.87.44]:46258) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw8Ab-0008A6-Bo for emacs-devel@gnu.org; Sat, 11 Dec 2021 14:36:35 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id 8BDA819EC53; Sat, 11 Dec 2021 20:36:31 +0100 (CET) X-Mailer: emacs 27.2 (via feedmail 11-beta-1 I) In-Reply-To: <3437406.lxAJRBJNBK@galex-713.eu> Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281703 Archived-At: On Sat 11 Dec 2021 at 19:38, Alexandre Garreau wro= te: > Le sabato, 11-a de decembro 2021, 16-a horo kaj 38:10 CET Tomas Hlavaty a= =20 > =C3=A9crit : >> On the other hand, my notmuch (emacs email reader) database is 30GB and >> lives externally out of emacs without issues. > > in what format is it? sexps? https://getting-started-with-xapian.readthedocs.io/en/latest/concepts/index= ing/databases.html >> Why link sqlite and not xapian? >> Where does it stop? > > Yeah and why not akonadi and then mysql, which it uses. yeah > Akonadi is the reason why I wish so much to switch again from kmail to=20 > gnus, because Try notmuch;-) > =E2=80=A6but I still don=E2=80=99t switch, because the way kmail stores m= ail is of course=20 > at least partially incompatible with gnus, because all these databases ar= e=20 > so complex=E2=80=A6 With notmuch, Emails are stored in maildir. The notmuch database contains the search index and user tags. You can always migrate to whatever supports maildir. Or reindex your emails. Tags can be exported/imported as simple text. > And I think that a fear of getting a such thing into emacs, under the=20 > excuse that =E2=80=9Cfor the developer, it works=E2=80=9D and that =E2=80= =9Cit brings more=20 > features=E2=80=9D is what makes people afraid from something even as mini= mal as=20 > sqlite=E2=80=A6 for emacs is one of the very few software to be minimal a= nd=20 > transparent enough to have a better situation than sqlite Databases are complex. Suitability of sqlite depends on the use-case. It is a leaky abstraction. For example, will users have to deal with schema upgrades? Will they have to deal with sql? Will they have to deal with sqlite specific issues? Once sqlite is linked into emacs, it will eventually infest almost everything and emacs will be stuck with it forever. Also I find the trend of linking everything into the emacs process concerning: $ ldd .emacs-27.2 | wc -l 107 Strangely enough, sqlite is already there: $ ldd emacs-27.2 | grep sqlite libsqlite3.so.0