Re: -1 on features draft

["Sylvain Hellegouarch" <sh@xxxxxxxxxx>]

>
> No one is saying that feature negotiation is required.  There is a
> reason that I never pushed for this to be added to the core Atompub spec.
>
> Blog client implementors have already developed and deployed mechanisms
> for feature discovery and it has very little to do with whether or not
> the client will try to communicate with a server and everything to do
> with allowing the client to selective enable/disable options that are
> presented to users.. users who typically have a negative reaction when
> they invest time trying to do something only to find out after the fact
> that they can't.

I agree. I believe that feature negotiation is a response to the "the
server has total control" of AtomPub core. Basically servers will be
pushed to implement common or trendy features if they want to have the
largest set of clients panel.

I don't think features will be pushed so much by server implementors
except maybe on some specific cases, such as authentication scheme for
instance that would help clients to understand what is the favourite
scheme supported  by a server.

Features are all about making AtomPub richer than the basic CRUD operations.

- Sylvain

>
> - James
>
> Roy T. Fielding wrote:
>> On Sep 11, 2007, at 9:12 AM, James M Snell wrote:
>>
>>> We've covered this in previous threads.  Atompub is not must understand
>>> but you simply cannot ignore the fact that there are existing
>>> implementations in the wild that implement must understand options.
>>> Examples include required support for specific authentication schemes,
>>> required support for HTTP conditional requests, required support for
>>> specific format extensions, required support for certain atom:content
>>> types, etc.
>>
>> None of which require feature negotiation.  The client needs to try
>> to do something and the server needs to respond appropriately,
>> regardless of what the features list might say.  The appropriate
>> response will tell the client what features it is missing.  If you
>> code the client such that it never tries until it is ensured some
>> mystic level of success, then you couple the client implementation
>> to a given set of today's server features, and everything stops working
>> when one of those presumed-to-be-required features turns out to be
>> an unusable security hole.
>>
>> ....Roy
>>
>>
>