Re: [Monotone-devel] ..more notes about .nuskool

[Zbigniew Zagórski]

2008/2/4, Markus Schiltknecht <address@hidden>:
> However, ATM nvm.nuskool is pretty simplistic and works over HTTP
> exclusively, ignoring any branch patterns and synchronizing all
> revisions in the database.

Just for curiosity how big databases you've managed to sync ? Is it
useful for syncing n.v.monotone* branch set ?

> I'd like to go for something more RESTful, as far as the HTTP interface
> is concerned. This should make better use of the HTTP caching
> infrastructure and would probably even allow something like the "mtn
> dumb" server interface.
>
> If we still need olskool netsync (do we?), we should encapsulate the
> communication channel stuff from the nuskool new DAG based refinement
> thingie, very much like the current refiner is separate.
>...
>
>   1.) sync from mtn client to dumb http server with static files
>   2.) sync from mtn client to clever http server via scgi to mtn server
>   3.) sync from mtn client to clever mtn server via netsync
>
> While the first two require a state-less approach, fitting HTTP, the
> third option doesn't. I'm not sure if it's worth exploiting that.
> Probably not. And the first option is quite different in that we cannot
> put any logic into the server, for obvious reasons.

Maybe a little not related opinion.

I've been thinking a lot about all of this while hacking on
n.v.m.dumb. I know that current dumb tool can be much more faster if
it would be possible to retrieve complete
merkle_dir (or anything representing state of the database/project) in
some fast way. The HTTP time wasn't too important, the most time
consuming was retrieving/toposorting all revisions (not so bad) and
all the certs for all revisions (ages).

It's slow also for current netsync protocol so I think there must be
some idea shift about synchronization. How to synchronize databases
without retrieving WHOLE of tree and ALL certs.

-- 
Zbigniew -zbigg- Zagórski
/ software developer / geek / happy daddy /