From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/75120 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus-sync ideas Date: Thu, 16 Dec 2010 10:33:26 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <8739pxsmnd.fsf@lifelogs.com> References: <87zks9ecf7.fsf@dod.no> <87r5djxahm.fsf_-_@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1292517265 29519 80.91.229.12 (16 Dec 2010 16:34:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 16 Dec 2010 16:34:25 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M23475@lists.math.uh.edu Thu Dec 16 17:34:21 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 1PTGma-0001CS-R4 for ding-account@gmane.org; Thu, 16 Dec 2010 17:34:21 +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 1PTGlz-00037F-95; Thu, 16 Dec 2010 10:33:43 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PTGlx-00036y-R2 for ding@lists.math.uh.edu; Thu, 16 Dec 2010 10:33:41 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PTGlw-00055J-EL for ding@lists.math.uh.edu; Thu, 16 Dec 2010 10:33:41 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PTGlv-0003wU-N1 for ding@gnus.org; Thu, 16 Dec 2010 17:33:39 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PTGlv-0000l2-Ff for ding@gnus.org; Thu, 16 Dec 2010 17:33:39 +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 ; Thu, 16 Dec 2010 17:33:39 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Dec 2010 17:33:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 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:sSD6nhtggDDnUwITONUYVbSLevI= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:75120 Archived-At: On Thu, 16 Dec 2010 11:06:04 +0100 Julien Danjou wrote: JD> On Wed, Dec 15 2010, Ted Zlatanov wrote: >> - splitting rules (trivial but needs a view/edit interface) JD> I do not see why it's not a configuration (elisp) thing. I'm trying to share the configuration between Gnus installations. Splitting rules are an essential part of the configuration. >> - BBDB (hard but very important, and useful beyond Gnus) JD> I do not see the point. I take it you don't keep your BBDB under VCS and endure merge pain when you update a record from different machines? >> - topic hierarchy (medium) JD> I do not see why it's not a configuration (elisp) thing either. Because topics are an essential part of the Gnus experience, so I think synchronizing them would make it easy to "just run Gnus" on a different machine. >> - subscriptions (but the user can pick subsets as the "work" and "home" >> setup for instance) (hard) JD> Replace "level" by tags? But once again, that is a configuration stuff. JD> That should just be a Lisp list in a .gnus you just C-M-x to update. Same as topics and splitting rules. JD> You're mixing 2 problems IMHO. You want to do data synchronization above JD> several places, and export Gnus state data so they can be reused easily JD> with other Gnus instances. Yes, AKA data-sync.el and gnus-sync.el. JD> I think the latter is a problem you can solve, but trying to resolve the JD> data synchronization is not an Emacs problem. I do not want Emacs to JD> mess with my storage strategy nor I want you to make some cloud storage. JD> I mean: that's not the point. JD> I store my Emacs configuration in my home, in a git repository. That's JD> my choice. I could also store my home on a webdav exported storage, NFS, JD> or whatever. That's my cloud, my business. Do not try to provide JD> something else: I do not want you to, nor I'd like an Emacs specific JD> solution. Sure. But nothing has *merge* support for ELisp data structures, that's the problem. Thus data-sync.el will provide merge strategies. If you choose not to use it, you're just versioning your Gnus configuration, which is fine. But people want to merge marks and other data between Gnus installations and Git will NOT do that correctly when there's a conflict. So basically you don't like data-sync.el. That's cool. You'll be able to just use gnus-sync.el with an "overwrite-only" data-sync.el backend, I promise. And that backend will behave like a file (in fact it will generate something much like newsrc.eld), and there will be much rejoicing. JD> If you want the users to change subscriptions or their levels, there is JD> a common interface called `cuztomize' which I think is done just for JD> that, and can dump Lisp code in your configuration file. But Customize is a) sucky, b) can't handle merging, c) doesn't do large data sets well, and d) is REALLY hard to modify at this point because so many users and libraries depend on its exact behavior not to change. So I don't think it can handle what Gnus needs. Ted