From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Tue, 14 Dec 2021 20:33:36 +0200 Message-ID: <83r1afjatb.fsf@gnu.org> References: <87tufmjyai.fsf@gnus.org> <87lf0nr2b4.fsf@gnus.org> <87fsqvp5ae.fsf@gnus.org> <432990EE-81AA-4312-8C94-6E87F7925647@mit.edu> <877dc7p50e.fsf@gnus.org> <83y24njfzy.fsf@gnu.org> <13641654-02AD-48D0-B5CD-EB390CE3594E@mit.edu> <83v8zrjdsh.fsf@gnu.org> <3A1A7C04-EF3C-44D9-B777-7F91E2329C15@mit.edu> <83sfuvjcmu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1243"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Qiantan Hong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 14 19:34:37 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 1mxCdJ-00007J-Ao for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 19:34:37 +0100 Original-Received: from localhost ([::1]:59114 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxCdI-0000Vt-7X for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 13:34:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxCcN-00084C-QB for emacs-devel@gnu.org; Tue, 14 Dec 2021 13:33:43 -0500 Original-Received: from [2001:470:142:3::e] (port=49608 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxCcN-0006CM-DO; Tue, 14 Dec 2021 13:33:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=sOuNXwS5zpHYHnJJ/FGB94W6tbV0EbFzZe5yNwNjHHU=; b=iYu63ZAS6A86el+3WC/K ELe8C1glh8ATVIHUjMPcI++bspd8AFZAuS7ctVNS1uGq93EgQwjCT5dYE6RtSdENfwa3D7sRTWAk/ hmSPa+Zd0nvg3IQ8Kw9liiG7xMMIeA7Tg1Kc+dFKAJk4Er2rkK6rkrKdf/tjlXNUzdDcAbPD1bKZW vOxdMawo15mHdOSEz28jmJEniUPZkQ5IVwB5v9jGDvAQP73h0HWCPxxH2cTcspQk/vD0VAKi06TR6 8gzftM80a6clMSE+ybo5+hntwqOIcBgLocMrAaGxz24o3SyU2NmZRUe4F17u/JJQmtutyRkyyE1+J OjrAS6fGJrJkCg==; Original-Received: from [87.69.77.57] (port=4498 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxCcN-0002KP-7y; Tue, 14 Dec 2021 13:33:39 -0500 In-Reply-To: (message from Qiantan Hong on Tue, 14 Dec 2021 18:04:35 +0000) 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:281938 Archived-At: > From: Qiantan Hong > CC: "larsi@gnus.org" , > "emacs-devel@gnu.org" > > Date: Tue, 14 Dec 2021 18:04:35 +0000 > > > Assuming we decide that extending what we have is indeed necessary; > > that is not a given. And if we do decide, I see no catastrophe: we > > are doing this all the time, keeping backward compatibility as we go. > > There's no need to be afraid of that. > Sure. I can see many cases where store.el interface is more suitable > than multisession.el, particularly when a package need… literally a > persistent store… that is basically a persistent hashtable, with key > not necessarily symbols. One example is org-id. Guess I’ll try > to put store.el on Elpa first and see if those package will use it. Yes, letting people use it will give us more useful data to base our decisions on. > As for compatibly, I must be understanding something wrong. > I thought that any interface that went into master must be kept. That is in general true, and I'm saying that we have good experience extending existing interfaces without breaking backward compatibility.