Re: [Monotone-devel] usher

[Thomas Keller]

Am 15.04.2010 04:50, schrieb Timothy Brownawell:
>> Maybe there is a third way, which would require changes in monotone
>> though: what about picking the database / server to use for netsync
>> directly from the client? I vaguely remember that we introduced an URL
>> schema in monotone a couple of versions ago (0.40 or so) and while its
>> nowhere documented beside in NEWS (not even functional in 0.47 for me
>> anymore, I get a network error "service name resolution failed for:
>> mtn", but the lua test still seems to run through),
> 
> Huh, that's not good.
> 
> ...I don't get that error, but it's treating the whole thing as the
> pattern instead of parsing it out. Different behavior, maybe something's
> uninitialized? Something more to look at, I guess...

I haven't looked into that any further, but I'm putting that on my
agenda. Especially since the unit tests still seem to run through this
might as well be some kind of weird local / shell error (I'm using zsh
here).

>> it looks like it
>> could be used for that:
>>
>>     mtn://monotone.ca?include=...&exclude=...
>>
>> What about expanding this to
>>
>>     mtn://monotone.ca/server?include=...&exclude=...
>>
>> and adding some logic the normal mtn server to bail out if the /server
>> part is found for a non-usher server?
> 
> The server can't tell the difference, so it can't know to bail. But then
> it probably doesn't really matter.

Well, the "server" part would probably be the same as some kind of new
--server option we introduce for netsync and this needs to be serialized
in the data stream to the server somehow, so of course once the code has
been adapted for that, it should just ignore it. We might have to
introduce another netsync version for this though.

>> I'd also look into adding support for these kind of URIs to mtn clone,
>> which currently still needs a branch argument.
> 
> I suppose that should be
>    mtn://monotone.ca/server?branch=...
> ?

Out of my head I'd have said "use the `include`" argument and let clone
check if only one include pattern is given (without expansion syntax),
but it might be better to have a dedicated branch argument for that. The
interesting question is how this argument is interpreted when used in
"normal" netsync operations - especially when further `include` and
`exclude` arguments are given. We could make it mutual exclusive, i.e.
either let them give a branch argument or a list of include / exclude
patterns, what do you think?

>>> I suppose this isn't that big a deal,
>>> might as well just tag current head as a release I guess?
>>
>> Thats right - I also wondered if its worthwhile to merge-into-dir usher
>> to the main monotone tree and include it in the base distribution. Usher
>> makes only very very little sense without monotone and if its packaged
>> right with monotone, you would not need to spend time setting up a web
>> page, bug tracker, etc pp, but the development of both could be
>> synchronized.
> 
> Hm. Or do we want a separate branch, with monotone and the various tools
> (usher, viewmtn, guitone, mtn-viz) all merge-into-dir'ed into it?

I don't think thats a good idea, because it puts the burden on the
person which manages this branch to keep all tools compilable and
running together, and at least for mtn-viz this is a problem, because
nobody took up the maintenance from Olivier for this until now.

No, I thought that only merging usher into monotone's dir makes the most
sense, because its a very useful and probably quite often needed
extension for monotone and we could tie both parts better together (f.e.
you wouldn't need to use your own copied basicio class). Just as mtnopt
is part of the distribution today, usher would be another supplement for
multi-database serving.

>> 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...

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.

> 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?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature