releases

[Lennart Poettering]

On Mon, 07.06.10 10:51, David Zeuthen (zeuthen at gmail.com) wrote:

> 
> Hey,
> 
> On Mon, Jun 7, 2010 at 9:51 AM, Christian Dywan <christian at lanedo.com> wrote:
> >> What is wrong with the current negotiation? It's perfectly streamable
> >> and leaves room open for future addition of negotation arguments. What
> >> do you want?
> >
> > Have a look at the comments in bug #27857. Basically adding a
> > new feature right now means repeating the whole negotiation with
> > commands specific to the new feature. So what I would like to see is
> > being able to handle any number of features in one go.
> 
> Specifically this is
> 
>  http://bugs.freedesktop.org/show_bug.cgi?id=27857#c12
> 
> When I talked to Lennart about this a couple of weeks back his
> response was "just use pipelining!". While it's true this will "solve"
> the problem, I don't think it's useful as it will complicate
> implementations (which are security sensitive code already) and make
> debugging slightly harder.

Well, I am pretty sure that it is much easier to handle each line
individually and as the only command token then adding a second
dimension to it and also split up each negotiation line into words that
are distributed nego commands.

And also, how do handle parameters if you line them all app? If you push
for that, you'd have to come up with a syntax for arguments *right now*
that is safe for the future. I am listening...

Also, why would lining things up be any nicer for debugging? Let's say
we add a couple of more negotiation features with args. Do you really
think thios is easier to read:

NEGOTIATE FOO BAR WALDO[7652jhg345672534juh] BAZ[path=/tmp/kjsdhfke45] FLUX[url=http://%2F::1%2F/4711] SUPERDUPERFEATURE[WITH_AN_ARG=OF_THIS_VALUE]

than this:

NEGOTIATE_FOO
NEGOTUATE_BAR
NEGOTIATE_WALDO 7652jhg345672534juh
NEGOTIATE_BAZ path=/tmp/kjsdhfke45
NEGOTIATE_FLUX url=http://[::1]/4711
NEGOTUATE_SUPERDUPERFEATURE WITH_AN_ARG=OF_THIS_VALUE

The more features you get the harder it is to read it if it is all in
one line. And harder to parse too. You'd need escaping, yadda yadda. And
what happens if the argument is a 4K blob or so. That'd just be ugly in
one line.

Also, on top of that: what happens if one feature you nego is dependant
on another? If you just allow one nego line, then you can never express
something like that. If you allow multipl nego line, you could send one,
and then the line for another feature only on reply of the first.

I really see little value in changing this behaviour, as I have not
heard any good reason for doing what you suggest. D-Bus is stalled in its
development, would be great if we would not waste any time on "fixing"
problems that basically just boil down to matters of taste.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4