Re: [Nbd] Back to the options parsing debate

[Goswin von Brederlow <goswin-v-b@...186...>]

Alex Bligh <alex@...872...> writes:

> 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.
>
> 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.
>
> libxml is pretty easy to use, and as the xml goes through only at
> mount time, it's hardly speed critical.
>
> Just a thought.

-rw-r--r-- 1 root root 153K Apr 24 15:18 /usr/lib/libxml++-2.6.so.2.0.7
-rwxr-xr-x 1 root root 15K May  9 20:30 /sbin/nbd-client*

Strike 1.

XML is basically nothing more than a tokenizer. You then still need to
define a grammar to make sense out of the data contained in the xml.
So all you did so far is add an obscuring encoding.

Strike 2.

Last the options would be a back and forth with queries and replies. A
negotiation of capabilities and so on. XML does nothing for this.

Strike 3. You're out.

MfG
        Goswin