Re: gnus-sync ideas

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> So, data-sync.el would let you:
>
> 1) choose a storage backend, which can be many things but will at least
> have the choice to be a file (which, of course, can use Tramp).
>
> 2) query a key and find out the latest value, data type, CAS key, and
> timestamp (you'd use the CAS key in the CAS ops below)
>
> 3) set a key with a data type (unconditionally or CAS)
>
> 4) delete a key (unconditionally or CAS)
>
> 5) merge data into a key with a data type and a policy (overwrite,
> prepend, append, set-if-present, set-if-absent) (unconditionally or CAS)
>
> 6) do all of the above as a batch

If there's one thing that the nnimap experience shows, then it's that
round trips kill you.  So ideally the client would issue just one
command, like

GIVE-ME-DATA-CHANGED-SINCE 12167121621 <filter that says what data I want>

and then we'd just get a stream of data back.

So all CRUD operations to the store has to be timestamped and
categorised for this to be fast, I think. 

As for how to actually store things like, say, the group topics...  I
don't really have a clear idea how that would actually look...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen