releases

[Lennart Poettering]

On Mon, 07.06.10 15:51, Christian Dywan (christian at lanedo.com) wrote:

>
> Am Mon, 7 Jun 2010 14:50:23 +0200
> schrieb Lennart Poettering <mzqohf at 0pointer.de>:
>
> > On Mon, 07.06.10 13:59, Christian Dywan (christian at lanedo.com) wrote:
> >
> > > I would like to see the negotiation changes and Maybe types in 1.4
> > > because the current negotiation is completely unflexible. Those
> > > go intuitively hand in hand I think, so it makes a lot of sense to
> > > me, in terms of having 2 types to actually make use of the more
> > > flexible negotiation. That said, if it is clearly voted against, I
> > > am also
> >
> > 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.

Uh? Where is there a discussion about caps?

Could you please explain this?

Is this another iteration of this dreaded discussion:

NEGOTIATE foo
NEGOTIATE bar
NEGOTIATE baz

vs.

NEGOTIATE foo bar baz

?

Well, I have already pointed this out a couple of times, and I will
point it out again: negotation needs parameters. Maybe not in the case
of simply boolean of types supported yes/no features. But it is
necessary for anything more complex. Example: if you negotiate support
for something like SHM data transfer, then you want to establish a
common shm seg between both sides, and you need to negotiate the
identifier for that. And there are probably more features with params
than without. And the "NEGOTIATE foo bar baz" syntax is just broken for
that, because you then would have to define how arguments are formatted
and that is hard to do in a way in a future-proof way.

NEGOTIATE_UNIX_FD
NEGOTIATE_MAYBE
NEGOTIATE_SHM path=/dev/shm/foobar size=4096

Ist just a lot nicer and easier to parse than

NEGOTATE UNIX_FD MAYBE SHM[PATH=/dev/shm/foobar SIZE=4096]

And it is equally streamlinable.

So if I have to say anything in this, then merging all the negotiation
stuff into one line is really bad idea. Don't do that. Keep things in
seperate lines, and send them all at once.

Also, your patch seems to suggest that the application should have
a say what is negotiated or not. What's the point of that? This is a
technical detail of the underlying protocol. The app should able to
test whether something is supported. It should never ever have to ask
for any feature in the first place. That would just be stupid idea and
bad API design.

Lennart

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