[Monotone-devel] Re: dumb servers

[Zbynek Winkler]

graydon hoare wrote:

> Zbynek Winkler wrote:
>
> > I like the option to have a "mirror" of the my database somewhere on 
> > the server accessible to anyone at any time and when the server does 
> > not have to be smart it extends my choice of servers.
>
>
> yeah, I understand this. but we've been experiencing some difficulty 
> with the temporal log-based model of communication, so I'm considering 
> other alternatives. if such alternatives can be made to work on "dumb" 
> servers, all the better; but I'm more concerned with figuring out 
> which model of communication is convergent, robust, self-stabilizing, 
> etc. than I am insisting that the server be a pre-existing bit of 
> internet infrastructure. if it requires a custom server, I'm willing 
> to pay that price, if it gets us big robustness improvements.

Sounds reasonable enough.

> > you would have removed the these things? Suppose you have two people 
> > working on a project that are rarely online at the same time... Do 
> > you propose to sync the two databases each of them have on the 
> > workstations?
>
>
> they would sync via a server or peer which *is* online all the time. 
> that's sort of the nice thing about hashtree synchronization: it's 
> really just set union, so if I sync with a server then you sync with 
> the same server, you have all my changes. if I sync with the server 
> again later, I have all your changes. it would replace probably 10 
> different commands in monotone with just one: "monotone sync <url>". 
> things which reduce the amount of code so dramatically are very 
> attractive.

:-) I can understand that. It would be much more *elegant* (note the 
epigraph at http://www.faqs.org/docs/artu/transparencychapter.html).

> > While thinking more about this - depot.cgi could function as a subset 
> > of monotone knowing only how to sync databases. Is this what you meant?
>
>
> I haven't made any sort of personal decision about whether to try to 
> layer such synchronization on top of HTTP or otherwise. it's a really 
> different model than log-replay; the only thing I am pretty sure of is 
> that SMTP and NNTP won't fit. I'm going to experiment with using a 
> "raw" file-descriptor based synchronization protocol between a couple 
> experimental peer programs. if I can get that working, and get a good 
> feeling for it being a robust algorithm, I'll look into whether we can 
> wedge it into HTTP+CGI (or FTP/SFTP), or need to use a custom server.
>
> I'm sorry if this all sounds like a disruptive surprise, 

At the beginning it was. But you've convinced me ;-) It all sounds very 
reasonable.

Zbynek

> but I've never *really* been satisfied with the networking system in 
> monotone -- it's efficient, but a bit too fragile -- and I'd prefer to 
> run some experiments to see if I can make it better. I promise I won't 
> make it worse; if this stuff doesn't work in experimental runs, I 
> won't touch any of the existing code.
>
> -graydon


--
http://zw.matfyz.cz/     http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic