From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/75093 Path: news.gmane.org!not-for-mail From: Julien Danjou Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus-sync ideas Date: Thu, 16 Dec 2010 11:06:04 +0100 Message-ID: References: <87zks9ecf7.fsf@dod.no> <87r5djxahm.fsf_-_@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1292494014 8676 80.91.229.12 (16 Dec 2010 10:06:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 16 Dec 2010 10:06:54 +0000 (UTC) Cc: ding@gnus.org To: Ted Zlatanov Original-X-From: ding-owner+M23449@lists.math.uh.edu Thu Dec 16 11:06:50 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PTAjZ-0007xu-Kq for ding-account@gmane.org; Thu, 16 Dec 2010 11:06:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PTAiy-0000dl-HU; Thu, 16 Dec 2010 04:06:12 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PTAix-0000dW-3N for ding@lists.math.uh.edu; Thu, 16 Dec 2010 04:06:11 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PTAiv-0007xA-AK for ding@lists.math.uh.edu; Thu, 16 Dec 2010 04:06:10 -0600 Original-Received: from coquelicot-s.easter-eggs.com ([213.215.37.94]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PTAit-0005L8-Ju for ding@gnus.org; Thu, 16 Dec 2010 11:06:07 +0100 Original-Received: from cigue.easter-eggs.fr (cigue.easter-eggs.fr [10.0.0.33]) by rose.easter-eggs.fr (Postfix) with ESMTPS id 9B5F5141AA; Thu, 16 Dec 2010 11:06:03 +0100 (CET) Original-Received: from jdanjou by cigue.easter-eggs.fr with local (Exim 4.72) (envelope-from ) id 1PTAir-0002pM-4X; Thu, 16 Dec 2010 11:06:05 +0100 Mail-Followup-To: Ted Zlatanov , ding@gnus.org In-Reply-To: <87r5djxahm.fsf_-_@lifelogs.com> (Ted Zlatanov's message of "Wed, 15 Dec 2010 10:32:37 -0600") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:75093 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 15 2010, Ted Zlatanov wrote: > OK, let's throw some gnus-sync specific ideas around. Assume the > current implementation is just a prototype and can be entirely thrown > away. Also assume I will work on this soon-ish but am happy to let > others contribute up to 100%. Finally, let's say one of the goals is to > eliminate newsrc.eld and other Gnus config files entirely or at least > make them a gnus-sync storage backend. So far, so good. But I know nothing about current implementation. > First of all, how should it operate in Gnus? IMO it should be immediate > and not triggered as it is now; a sync should happen every time you > enter or exit a group (and can also be triggered explicitly). Here we > can use the hooks I added recently: `gnus-after-set-mark-hook' and > `gnus-before-update-mark-hook'. Fair enough. > Second, how should the data be stored? IMO it should be stored in a > free-form key-value format but the storage backend should be able to > understand the rtree format; the ELisp list, vector, and plist formats; > and maybe JSON and merge such data (with parameters that control how the > merge will happen). I think a custom network server would actually be > the best storage backend solution here; imap-hash.el could also work > with some love; the file storage backend is also sensible to duplicate > the current newsrc.eld functionality; and, of course, people will come > up with a Git-based and RDBMS-based storage backend Because They Can. Thanks, I use git, so storing it inside git would be good for me, and probably the simplest way. :) > Third, what data are we storing? I think marks should only be synced > for news-p backends. But we should generally be able to save, in order > of importance IMHO: > > - marks for news-p servers (medium difficulty) That's the only thing that really matters IHMO. > - splitting rules (trivial but needs a view/edit interface) I do not see why it's not a configuration (elisp) thing. > - BBDB (hard but very important, and useful beyond Gnus) I do not see the point. > - topic hierarchy (medium) I do not see why it's not a configuration (elisp) thing either. > - subscriptions (but the user can pick subsets as the "work" and "home" > setup for instance) (hard) Replace "level" by tags? But once again, that is a configuration stuff. That should just be a Lisp list in a .gnus you just C-M-x to update. > - the Gnus registry (medium) Why not. > So because this is such diverse data I think the storage backend should > just be a key-value store. The rtree/ELisp data merge support is really > the only thing special about it. And maybe it's not a Gnus-specific > thing but could be useful for Emacs in general, in which case it should > be called data-sync.el and the Gnus glue is gnus-sync.el. I'm sure the > org-mode users, for instance, would like this kind of functionality too, > and maybe they already have it and we can just steal it :) You're mixing 2 problems IMHO. You want to do data synchronization above several places, and export Gnus state data so they can be reused easily with other Gnus instances. I think the latter is a problem you can solve, but trying to resolve the data synchronization is not an Emacs problem. I do not want Emacs to mess with my storage strategy nor I want you to make some cloud storage. I mean: that's not the point. I store my Emacs configuration in my home, in a git repository. That's my choice. I could also store my home on a webdav exported storage, NFS, or whatever. That's my cloud, my business. Do not try to provide something else: I do not want you to, nor I'd like an Emacs specific solution. OTOH, I'd like to be able to reuse data synchronization from backends that can store some information, like nntp (or nnrss, or anything else), and move away things that have nothing to do in here, like for example subscriptions or subscriptions levels. If I want to split things for work and home, I can write it easily in Lisp. If you want the users to change subscriptions or their levels, there is a common interface called `cuztomize' which I think is done just for that, and can dump Lisp code in your configuration file. Let me write Lisp! (Sorry if the end of the mail is a little off-topic.) =2D-=20 Julien Danjou =E2=9D=B1 http://julien.danjou.info --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0J5I0ACgkQpGK1HsL+5c1x1gCfRbOivyHdl5qpHr9i6aC8xHlP 6pkAn1lozTjVRyXaJ6zSm1tRRAxRHI37 =jnbi -----END PGP SIGNATURE----- --=-=-=--