Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt

[Darrel Miller <[e-mail]>]

Mike,

How do you feel about a link relation that says, if you do POST, it
means this ...

If that concerns you then do you have suggestions on how the these
link relations should work:

rel=payment        https://web-payments.org/specs/source/payment-links/
rel=hub
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
rel=oauth2-token http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8

As far as I understand it, all of these have an associated meaning to
a POST request.  Curiously, that meaning is not described in the rel
relation registration, but in the specification that describes the
protocol that uses the link relation.  This separation concerns me
because we could end up with a situation where different protocols
assign different interaction semantics to the same link relation.

Darrel



On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <[e-mail]> wrote:
> My advice is to *not* attempt to constrain how the client or server behaves
> when using the link relation (e.g. "client SHOULD use POST to ....", etc.).
>
> Instead just define the link relation's meaning and let clients and servers
> use that shared meaning to do whatever they want with it.
>
>
>
>
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://linkedin.com/in/mamund
>
>
> On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
> <[e-mail]> wrote:
>>
>>
>> On 15.01.2014, at 16:59, Erlend Hamnaberg <[e-mail]> wrote:
>>
>> >
>> > My use case has been a schedule for a conference.
>> >
>> > The program is built over time, but once it is done, I want to publish
>> > it.
>>
>> If publishing is done by the same server, I'd change a property of the
>> program to tell the server that it should publish.
>>
>> When on a nother server, I'd try to POST the program's representation,
>> implicitly creating a new publishing job. That job will have a URI which I
>> would use to observer the state of the job.
>>
>> Having "publish" point to the publishing system might make sense, in that
>> sense "publish" would identoty a "resource providing publishing services".
>>
>> I'd ovoid to POST the URI to the publishing service if possible, because
>> it reduces simpicity IMHO, because the publishing system will need to go and
>> GET the resuorec to be published which feels unnatural to me.
>>
>> How does that resonate with you?
>>
>> Jan
>>
>> >
>> > I could, of course, go through each session and publish it directly.
>> > Each publishing step is then a state change for each session.
>> > However, for a user interface can become cumbersome.
>> >
>> > However, If I decide to model this as two separate URIs,
>> > I may need a different mechanism.
>> >
>> > Not sure I am able to explain this appropriately.
>> >
>> > Erlend
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>