Re: [Monotone-devel] monotone dumb progress

[Nathaniel Smith]

On Wed, Mar 22, 2006 at 12:34:16PM +0100, address@hidden wrote:
> I almost finished, my first add-on to "monotone.dumb" subproject it includes:
>   mtndumb
>     A command line wrapper with "pull/push/sync URL" actions.
>     Maybe we should rename it to mtn-dumb, monotone-dumb?
>   dws
>     A "Dumb Web Storage" FS implemented now only on PHP+PostgreSQL which
>     allows to sync your database to your cheap hosting site over HTTP. :)
>     Well, it will be cheap if I write driver for mysql ;).

Great!

Does it work for you?  Are you using mtndumb in real life?

Random question: what does it gain from using a RDBMS at all?  It
should be reasonable efficient to just use flat files, just implement
the WriteableFS interface (append to file, replace these files, etc.)
in the web app?  Is there some funky thing I don't know about, like
there are cheap web hosts that let you store a bunch in a DB, but
don't let you store a bunch in the filesystem as raw files, or
something like that?  Just seems like it might be even easier and
portable to just use the filesystem, but I really don't know the
area...

> Anyone interested?
> I'll package results as soon as i'll find a time.

Awesome!  Want to send us (me) a key, so you can just commit them to
the repo?

> Also, Nathaniel, does 'roster-centric' in 0.26 changes will make
> some difference for 'dumb' algorithm?
> Will your old 'dumb.py' implementation work with monotone 0.26?
> I don't have access to 0.26 now.

I think the only real problem added by 0.26 is that the parser that
finds file deltas will be broken by the new format.  Not too
complicated to fix.  Riccardo (address@hidden) just committed some
changes to help with 0.26 compatibility actually, I haven't had a
chance to look at them, you might want to talk to him...

There are a lot of other improvements to be made to the setup,
though :-).  The disk format could use some cleanup (the
locking/rollback isn't quite right, and I _think_ it is a win to
choose the merkle trie branching factor a little more
carefully/adaptively), it needs to use 'automate stdio' (0.26 puts the
necessary packet commands in 'automate', so this will be a huge speed
win), monotone needs to learn how to have epoch packets (a tiny point,
but useful for correctness) and to reference certs by some
user-visible id (this will be an even huger speed win), the SFTP and
HTTP support need to be faster (pipelining or something should be a
nice speed win, and ideally it should request multiple byte ranges all
at once for HTTP), it could do with FTP support at all, it would be
nice if it could run directly against a monotone db, just calculating
the necessary structures in memory rather than needing a local merkle
dir, the whole thing could use some tests...

I hope my list doesn't scare you off!  These are all pretty
incremental or straightforward, and I'm happy to explain anything
here better.  But maybe it helps give you some ideas for what might be
fun to work on next... ;-)

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender