Re: gnus-sync ideas

[Julien Danjou <julien@danjou.info>]

[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]

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.)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]