Re: [Monotone-devel] Question on layering

[Chad Walstrom]

I wrote:
> *shrug* It might be time to start investigating extending monotone
> to present an HTTP interface as well (i.e. mtn serve --protocol
> http).

Let me throw in a couple disclaimers to my suggestion.  I am a
non-contributing lurker and end-user.  My observations are by no means
authoritative.  It is my understanding that netsync is a very cool,
specifically designed network protocol.  The designers looked at HTTP
and decided to come up with their own instead.  So, RESTful or not,
HTTP may not be a viable option.  One place to start with this is
perhaps viewmtn.

On Wed, Feb 21, 2007 at 09:42:42AM +1100, William Uther wrote:
> It was to get around a firewall that I was using the ssh:// based
> syncing (until I found out is isn't recommended for general use).

Well, not for use where multiple users are frequently sync'ing at the
same time of day.

> i) anonymous pull over http(s).  By http(s), I'm referring to an
> already established server.

There is a "dumb server" wrapper to monotone written in Python.  It
can be found under net.venge.monotone.dumb.  I've used it once or
twice before in an older version, and it seemed to work well enough.
I don't know what the status of this code is with relation to the
current monotone version.

> The "pull from http"  needs to be in the standard client.

Not sure this will happen.  Wrapper clients aren't hard to get for the
push and pull aspect of it.  Representing the monotone database in
flat-files is a challenge, and it hasn't been viewed that it is
something that monotone needs to know how to do.

> ii) anonymous push over email attachments.  Something like "mtn
> push-email repos > attachment".  Then you email the attachment.  The
> receiver uses "mtn read < attachment".  The push-email command needs
> to be in the standard client.  The mtn doing the read will probably
> be the server from i (doesn't need to be the standard client).

That would be pretty cool. ;-)  The biggest limiting factor to this is
not being able to synchronize the state of the two databases over
email.  I think it would be possible to read in revisions in such a
manner, but only once partial pull support was in place.

>   iii) get ssh:// access working as a 1st class system.

I think it is a 1st class system.  You just can't have multiple
sessions open SQLite locking semantics for piped input, IIRC.  I don't
think this is a limitation the developers can get around.

>   vi) You need partial pull.

http://venge.net/mtn-wiki/PartialPull

-- 
Chad Walstrom <address@hidden>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */