Re: Issue-80: Post media types usable for Create; background for proposal

hello john.

thanks a lot for your feedback!

On 2013-06-10 10:14 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>>- another way ... introduce the concept of "link hints", currently
>>proposed (but not yet
>Thanks for the reminder Erik, it has been several months since I skimmed
>json-home.  Valid additional source of inspiration.

actually, as of yesterday,
http://tools.ietf.org/html/draft-nottingham-link-hint is the most
up-to-date source for the link hint work. it does make more sense to look
at this as a general concept, instead of making it a part of home
documents.

>"hints" are of dubious value to implementations.  If you act like you
>believe them and don't verify, then you're not treating it as a hint.  If
>you verify, why did you need the hint... the gratuitous variability
>argument I hear people raise on these matters.

you may have some misunderstanding here. hints are just optimizations. for
example, an "edit" link tells you that you can PUT or DELETE. a hint might
tell you that you shouldn't even bother to try to DELETE. this you can use
to for example drive a UI and gray out the "delete" button. you can of
course build UIs that never do that and always allow you to press "delete"
and the report back "couldn't be deleted", but hints fill a valuable gap
here (and yes, in some freak cases the DELETEability may change between
generating the hint and a client following the link, but nothing bad ever
happens, other than a client not following a link it could have followed
after a link hint refresh). it produces cost on the server side (evaluate
the resource permissions when generating the "edit" link, and not just
when receiving the request for the DELETE), but it also produces value. if
you don't like hints, then don't use them. everything works as before,
logically, but you'll end up with different interaction patterns.

>>point out that Accept-Patch really only talks about the HTTP
>>interactions,
>> without trying to go any further. in my mind, that's a cleaner way to go
>It has that luxury because the semantics of Patch are constrained in a
>way that does not apply to Post.

kind of. i see where you're coming from, but actually on the HTTP level,
there is no difference. POST and PATCH allow you to interact with a
resource, and you typically send some media type representation in the
request. the representation indicates what you want to do, for PATCH it
can be one of potentially a thousand different patch formats, for POST it
can be one of potentially a thousand different other formats that transfer
state from client to server.

>Do you have any sense for how fast json-home is likely to proceed to
>standard, relative to the LDP schedule in the charter?

as you may be able to judge from yesterday's spawning off of link hints
from json-home, things are still very much in flux. personally, i hope
that link hints will progress fast, since we simply need them in a variety
of places in our designs. how fast they will progress is impossible to
predict, but i think it's safe to assume that they will not have reached
the level of maturity in time to make them a solid foundation for LDP.

cheers,

dret.

Received on Monday, 10 June 2013 21:47:09 UTC