[leafnode-list] Re: Two (or more) systems synchronization

[Matthias Andree <matthias.andree@xxxxxx>]

Reiner Steib schrieb am 2007-10-07:

> On Sat, Oct 06 2007, Martin wrote:
> 
> > If I remember correctly, there's some solution with INN.
> 
> I also heard about this INN feature.  It would be nice to have such a
> feature in leafnode, i.e. fetch articles from a remote newsserver and
> keep the articles as on the server.  This scenario seems to be quite
> common.  It would probably require that there's only a single server
> (the "master") in the "slave's" leafnode setup.

Well, cloning/synchronizing article numbers might require some work to
leafnode, but is certainly doable (requires some internal work though
because currently storing articles is "use high level watermark with
automatic increment, but the supersedes code might help us getting where
we want), even if not on short notice.

Offering IMAP access however - well, that's going to be tough. I wonder
if a leafnode plugin for Dovecot (for instance) would be feasible,
worthwhile or reasonable.

I presume we require some cleaning-up of internal interfaces (namely,
encapsulate the whole article access in a module on its own).

However, I'm not going to be able to evaluate that in the next few
weeks, probably not in October (real-life obligations taking away my
time; fetchmail 6.3.9 is also way overdue and delayed).

> I've been using such a setup for years: On the main machine, there's
> the "master" leafnode spool.  Via rsync, I synchronize the spool (and
> leafnode config files) to the notebook ("slave" leafnode) when online.
> On the slave, I never run fetchnews.  This keeps the article numbers
> in sync.  Additionally you need to sync your .newsrc or similar file
> of your newsreader.
> 
> Caveats:
> 
> - Exclude out.going and failed.posting from rsync when doing the
>   master -> slave sync.  Instead, you need to sync out.going from
>   slave to master when online (and run fetchnews -P on the master).
> 
> - Matthias doesn't want to guarantee that the spool layout stays at it
>   is (traditional news spool: one directory per group, one file per
>   article, overview files) in leafnode2.  So this setup might break in
>   future versions of leafnode(2).

The leafnode-1 spool shall remain the way it is in 1.11.6 throughout the
1.11 series, and I seriously doubt I'll open another 1.X series such as
1.12. I want leafnode-1 to be feature complete, it is essentially frozen
and my plan is to include only bug-fixes -- however, either nobody is
using it any more or remaining bugs don't itch people enough so they
don't bother reporting them. If you think I've forgotten about your
favourite bug, feel free to remind me :-)

leafnode-2's spool format might change/break, yes. The main intention is
keeping the door open for using databases for active and overview data
to allow for more concurrency, and perhaps find some store method that
is faster than one file per article. The latter may however not happen
in leafnode 2.0. This beast needs to be finished somehow, and that won't
happen with loading the TODO list with new features and radical changes
;-)

-- 
Matthias Andree
-- 
_______________________________________________
leafnode-list mailing list
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
https://www.dt.e-technik.uni-dortmund.de/mailman/listinfo/leafnode-list
http://leafnode.sourceforge.net/