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

Re: [PATCH v3] doc: Define a standard URI syntax for NBD URIs.



On Tue, Jun 11, 2019 at 02:51:47PM +0100, Richard W.M. Jones wrote:
> On Tue, Jun 11, 2019 at 03:29:03PM +0200, Wouter Verhelst wrote:
> > Hi Richard,
> > 
> > LGTM, for the most part. One minor detail: should we document that the
> > URLs should only be used for newstyle connections? I don't honestly
> > think that using oldstyle is a good idea anymore, so we might as well
> > drop it and assume that people don't want to try oldstyle anymore, but
> > then...
> 
> We support it in libnbd and nbdkit!
> 
> Longer more serious answer: I don't think we should stop people using
> oldstyle even though I agree that newstyle is the superior choice in
> every respect.

I agree with that.

However, oldstyle and newstyle are not compatible[1]; so it may be
necessary for the URI to specify whether the connection should use
oldstyle or newstyle.

My first suggestion was going to be that we add a parameter to specify
oldstyle (the default should be newstyle); but then I was thinking that
not many servers would implement oldstyle anymore. Hence that
suggestion.

> One actual reason to still be using oldstyle is
> because you've got some old server which you can't / don't want to
> update.  I have encountered a few of these in niche places (VMware is
> one, and just about any hit for "NBD" on github that was started
> before 2010 will be using oldstyle).

Sure.

We can still add a "?oldstyle" parameter to specify oldstyle, or some
such. I just don't know whether it's worth it.

[1] theoretically it should be possible to detect the oldstyle magic
    number and fall back to oldstyle if supported, but that's a bit ugly
    and I don't want to write that in stone for clients/libraries that
    support it. It makes sense to require that oldstyle/newstyle is
    explicitly selected in the URI instead.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


Reply to: