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

Re: -1 on the features draft


James M Snell wrote:


Bill de hOra wrote:

[snip]

If you have a better proposal, I’d love to hear it.

Here: ww.xmpp.org, www.beep.org, www.fipa.org, www.w3.org/2001/sw/.
They've done much groundwork in terms of machine driven negotiation. You
could look at SSL/TLS handshaking as well I guess.



I'd be better swayed by a concrete example of how you would imagine
these alternative approaches working with Atompub.
If you want me to change my position, fix your spec. The onus is not on me to provide a better design. 



Also, keep in mind that the features draft is not about feature
negotiation, it's about feature discovery.. or more specifically, it's
about the server telling the client what implementation choices it has
made so that the client can make up its mind about what it's going to do
before it tries to do it.
I know. But you haven't provided a coherent language to state features. I have to know feature by feature what to do in advance. Combining that with mU makes this spec problematic for me. 



In particular, each sentence is called "feature" hence the feature spec.
But the overall effect is a language that can be used to define private
protocols tunneled over Atompub. I'm betting that language will suck,
and if it doesn't, it will be a coincidence given its implicitness.



Again, the f:feature element does not define anything.  Yes, the
f:feature element can be used to document the stupid choices people
might make when implementing their servers but that doesn't, by any
stretch of the imagination, legitimize those stupid choices.


It legitimizes the approach.



The mU thing is flawed, there's no way to express how features
relate to each other; in combination they represent point to
point wins at expense of overall fragility.

Stopping the features draft won’t reduce fragility unless a
better proposal exists. Vendors will make something up if they
have to, and if you think the features draft is bad, just *wait*
to see what *they* come up with.

Pleading about what vendors will and won't do doesn't sway me; If I did


And yet you're entire argument seems to be based on what you're afraid
vendors might do with the f:feature element.
Are you even following the arguments? I'm afraid that the proponents of the spec don't understand it. Failing to answer technical criticism, they resort to ad-populum or special pleading. Bad sign. 

cheers
Bill