Re: gnus-sync ideas

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 16 Dec 2010 11:06:04 +0100 Julien Danjou <julien@danjou.info> 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