monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] usher


From: Timothy Brownawell
Subject: Re: [Monotone-devel] usher
Date: Sat, 17 Apr 2010 10:39:16 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4

On 04/15/2010 02:13 AM, Thomas Keller wrote:
Am 15.04.2010 04:50, schrieb Timothy Brownawell:

Finally, what speaks against integrating usher in monotone's base
completly?

As in make it all a single binary? Not sure what the benefit would be,

Well, I haven't looked at the code and its probably too different from
mtn's network code, but I imagined a new "proxy" mode in `mtn serve`
which would do just what usher does today. And we'd instantly also get a
server-side administrative console within mtn itself to manage the
server's running netsync connections and server setups. But thats
probably too much and too hard for now...

Yeah, the code really is completely different. And probably not as good at the moment.

Let's concentrate first to put usher in a release-capable state so
packagers (like me :) can pick it up. If it packaged I'll have a much
easier way to convince the guys over there at indefero some time to
install and configure it as monotone helper for the use case.

Seems reasonable.

and I like the more modular approach. For instance I have a half-written
usher library in C# somewhere, I imagine that sort of thing would be
more difficult if usher was baked into monotone.

Out of interest - what does this library do?

It doesn't do much of anything at the moment. ;)

Mostly it's (meant to end up) like the standalone c++ usher, except with the admin interface and serverlist reader replaced with a function-call interface. The idea being that it might be easier to integrate with something serving a website interface, although it would have the downside of needing to interrupt any netsync connections in order to change the frontend. Perhaps a better choice would just be to expand the admin interface so it can be used to add/delete server definitions, and then have a library to wrap that.... depends on the goals I guess, having a single daemon would be easier to set up but more disruptive to upgrade than a pair that talk to eachother.


--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]