Re: [Nbd] Back to the options parsing debate

[Wouter Verhelst <w@...112...>]

On Sun, Jul 31, 2011 at 01:08:03PM +0100, Alex Bligh wrote:
> It occurred to me that we are reinventing the wheel with this a bit.
> Parsing options and lengths and so forth is error-prone, and is likely
> to result in interoperability difficulties.

Possibly.

> Extensible languages for describing options already exist. For a local
> hack here, I thought about passing the disk name an XML blob - this
> would allow me to pass the disk name and all sorts of other options
> right from the client without any new client-side coding. It then
> occurred to me that if the client passed what it wanted in an XML
> blob (including the disk name), perhaps with the server sending some
> XML at some stage too, perhaps this would be an easy way out of
> the extensibility issue.

I don't think so.

XML is very much overrated, IMO. A plain and simple byte-based protocol
can do just as much, though we wouldn't be (ancient)buzzword compliant
anymore then.

> libxml is pretty easy to use, and as the xml goes through only at
> mount time, it's hardly speed critical.

No, but nbd-client is space critical. While I don't mind adding
libraries to the server if it helps, it is absolutely necessary that
nbd-client can still be stored in an initramfs without too much of a
problem and without too much ram on the client. Adding a library that is
10 times the size of the binary itself is therefore a no-go.

Anyway, you do what you want to, but there's not going to be any XML in
the official nbd-client.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a