[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: dumb servers
From: |
Zbynek Winkler |
Subject: |
[Monotone-devel] Re: dumb servers |
Date: |
Sun, 18 Jan 2004 11:48:56 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 |
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