Re: -1 on the features draft

[James M Snell <jasnell@xxxxxxxxx>]

Bill de hOra wrote:
> [snip]
> 
> It's too easy to couple clients and servers, 

This is going to happen regardless of the feature spec.  It's already
happening in fact.  Any time any implementation uses any extension you
run the risk of coupling clients and servers.  I'm not trying to solve
this problem and I see no reason to think the f:feature element would
make it any worse than it already is.

> mU is a known to be broken idea that was designed out of Atom and Atompub, 

Agreed, but it's already happening regardless of the feature spec.
Which is better: to implement must understand features and let people
know about them up front or to implement must understand features and
not tell anyone until they start trying to do stuff and discover they
can't?  Obviously not having must understand features at all is best but
that's simply not an option.

> features won't compose cleanly, 

I don't know what this means

>features can be co-occurent

Yeah.. so?  Given conflicting features, the client gets to decide what
to do.

> there's no versioning model,

I am assuming that you're referring to versioning of features?  If so,
the fact that features are identified by IRI provides a good enough
mechanism to handle versioning.  That is, if you update a feature,
update it's IRI.

> there's no deprecation model,

We can easily add "deprecated" as one of the support levels.

> it can be used as a protocol toolkit, 

I don't know what this means

> it will lean people towards doing the wrong thing because it's
> fundamentally flawed for anything above point-to-point or lan scale
> systems. 

I don't know what this means.

>It has some of the problematic aspects of WS/RPC technologies.

Such as?

 > The feature spec is weak sauce. You'll have to do much, much better than
> blaming to me for pointing this out. If you think that any -1 to this
> spec also requires an improved design option, get the chairs/secretary
> to say that's how this group does its work.
> 

I'm not *expecting* an improved design option from you or anyone here --
I am, however, asking for one. I brought this spec to this WG because I
hoped the WG would provide constructive criticism and help guide it
towards something that works well for everyone. Unfortunately, however,
this thread has been heavy on the criticism and very light on the
constructive.  That's fine; you are, of course, under no obligation to
offer constructive suggestions for alternative approaches but not doing
isn't exactly helpful.

But, whatever.  At this point, I'm just going to wait to see what
suggestions Joe and Tim come back with and move forward from there,
likely as either an informational or experimental draft.

- James