From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/75025 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: gnus-sync ideas (was: Separating marks from other group configuration) Date: Wed, 15 Dec 2010 10:32:37 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r5djxahm.fsf_-_@lifelogs.com> References: <87zks9ecf7.fsf@dod.no> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1292430824 30734 80.91.229.12 (15 Dec 2010 16:33:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 15 Dec 2010 16:33:44 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M23381@lists.math.uh.edu Wed Dec 15 17:33:40 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 1PSuIK-0003LQ-Bd for ding-account@gmane.org; Wed, 15 Dec 2010 17:33:36 +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 1PSuHl-0002dG-Dk; Wed, 15 Dec 2010 10:33:01 -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 1PSuHj-0002d5-Es for ding@lists.math.uh.edu; Wed, 15 Dec 2010 10:32:59 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PSuHc-0003mw-Qk for ding@lists.math.uh.edu; Wed, 15 Dec 2010 10:32:56 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PSuHb-0003dC-FQ for ding@gnus.org; Wed, 15 Dec 2010 17:32:51 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PSuHa-0002mS-CN for ding@gnus.org; Wed, 15 Dec 2010 17:32:50 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Dec 2010 17:32:50 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Dec 2010 17:32:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 76 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:OVJB1WYJVSCEfEwIBOwRFnfohto= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:75025 Archived-At: On Mon, 13 Dec 2010 19:49:00 +0100 Steinar Bang wrote: >>>>>> Lars Magne Ingebrigtsen : >> Wouldn't it be nice -- if you had an IMAP server in your setup, then >> everything would be stored there? (I mean, in addition to the >> .newsrc.eld file, which would be used if you couldn't access the IMAP >> server.) SB> Ted has already had some thoughts in this line, about extending his SB> gnus-sync.el to cover stuff other than tick marks. 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. 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'. 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. 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) - splitting rules (trivial but needs a view/edit interface) - BBDB (hard but very important, and useful beyond Gnus) - topic hierarchy (medium) - subscriptions (but the user can pick subsets as the "work" and "home" setup for instance) (hard) - the Gnus registry (medium) 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 :) Fourth, for general accessibility, data-sync.el will have a simple view/edit interface to load a specific key in a buffer, edit it in Emacs Lisp, rtree, or JSON mode, and commit it back if it validates (no merge, just overwrite). This functionality could also connect with revisions if the storage backend supports them, so you could look at older versions of your data. Fifth, the network server storage backend should be easy to set up and run. Maybe a HTTP-backed implementation would make the most sense because those are so easy to set up and are not firewalled. Finally, what other parts of Emacs besides BBDB and org-mode could benefit from a general data-sync facility? WDYT? Ted