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

[mike amundsen <[e-mail]>]

I'm not a fan of using a string as a network affordance ;) I know this is
not a universally held conviction. for example, HAL relies on this very
notion quite heavily.

i assert the best way to use link relation values is as identifiers. The
registry let's use describe these values in a general way much the way a
 language dictionary (e.g. English, French, etc.) does. The way in which
the words are used, their intent, implied meaning, etc. are often based on
immediate context ("you owe me a payment" vs. "there is were you go to make
payments") and so forth.

To your last point, I think tying operational semantics to a link relation
is over-constraining and limits it's use over time. Esp. when the
operational semantics are tied to a single protocol or format. I prefer to
keep usage details separate from the registry of unique values.





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 3:58 PM, Darrel Miller <[e-mail]>wrote:

> 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
> >
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>