On Feb 15, 2010, at 9:42 PM, Santiago Pericas-Geertsen wrote:
>
> On Feb 15, 2010, at 2:48 PM, Jan Algermissen wrote:
>
>> I am not sure a generic approach is feasible because hypermedia can take many forms
>>
>> - links
>> - link templates
>> - forms
>> - exotic (as in http://www.nordsc.com/blog/?p=293#cbcID-tweak )
Actually forgot such kinds of links:
<app:collection href="
http://foo/service/collections/1"> or
<img src=""/>
>
> The general case may be very difficult to tackle indeed. I agree with your assessment.
However - there should really not be a very large number of media types (certainly we do not want one per service) and the set of media type specific plugins to provide would not be so big that it would not make sense to make them (in some way) part of the framework. As a plugin package maybe.
From this POV it would make sense to discuss general properties of such plugins.
It would also make sense to provide methods at the level of a user agent (not connector) class that allows acess to all the links present in the current steady state.
That way I could ask the user agent object if in the current steady state there is a 'ship' link. For the caller it would be transparent wether the link was in some response header or some representation that is part of the current steady state. And things like that should be transparent as they are semantically equivalent.
I could also envision a means to iterate over the items of a steady state that 'is' a collection. The actual primary representation of the steady state might be RSS or Atom feed or even text/uri-list but from a client program POV I just might not care.
So there is some kind of common ground to leverage.
Jan
>
> -- Santiago
>
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------