Re: Confusing terminology between usher and monotone and proposed change

On Thu, May 05, 2011 at 06:57:10PM -0400, Stephen Leake wrote:
> Richard Levitte <[email protected]> writes:
> 
> > I've had a closer look at the terminology used in usher and in
> > monotone, and there is a part that's quite confusing:
> >
> > In usher terminology, different databases are served by different
> > monotone server, and therefore, the URI to access them through a
> > server name would be expressed as mtn://HOST/SERVER?PATTERN.
> >
> > In monotone terminology, the same URI is expressed as
> > mtn://HOST/PATH?PATTERN.
> >
> > Furthermore, usher is a server in its own right, so when talking about
> > the usher+monotone combination, it might be confusing to talk about a
> > server, as it might not always be clear if you're talking about the
> > usher server itself or one of the underlying monotone servers.
> >
> > Also, in usherctl, the confusion is increased, since it uses PROJECT
> > to designate what usher calls SERVER and monotone calls PATH.  This is
> > confusing since monotone has another idea of what a project is, and
> > will just increase as soon as policy branches are in place.
> >
> >
> > To clear the confusion, I propose that we make a terminology change in
> > usher, where the term SERVER (to designate a monotone server entry in
> > the usher configuration) be changed to PATH (with the implicit
> > understanding that a PATH is then served by the monotone server in
> > said entry).  This makes it clear how it corresponds to what's in the
> > monotone documentation and leaves less (if any) confusion about what
> > server you're talking about in different contexts.  And frankly, I
> > like the ring of it ;-)
> >
> > The proposed changed involves having the key 'server' be replaced by
> > 'path' in usher's configuration file.  Of course, usher should still
> > understand the key 'server' for a while (say, until 2.0), but will
> > then tell the user that it's deprecated and should be replaced.
> > usherctl will be changed in a corresponding way.
> >
> > This should be implemented before releasing usher 1.0.
> >
> >
> > Thoughts?
> 
> looks good to me, but then I've never implemented an usher setup.

Well, even though I thought I got it to work last month, I'm still 
trying to figure out my usher setup (I probably forgot soemthing about 
how I used it) and I've found everything confusing again.  I'll retry 
understanding it with Richard's not in hand, and I'll tell you if it's 
become clear not in a few days.

Maybe this letter came just in time for me!

-- hendrik