jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Hypermedia - Take 2

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 02 Aug 2011 13:49:23 +0200

On 07/29/2011 07:19 PM, Santiago Pericas-Geertsen wrote:
>
> On Jul 29, 2011, at 12:06 PM, Markus KARG wrote:
>
>>>
>>> Do you have some cycles to put it in wiki form?
>>
>> Do you think it is worth the effort? I mean, it seems that my proposal has
>> no majority anyways.
>
> It's up to you, I think it may help getting everyone on the same page.
>
>>
>>>
>>> So you get a representation with URIs and resolved them eagerly before
>>> the application gets to the parts? I thought the whole point was to
>>> resolve the parts _on demand_. That's certainly what a browser would
>>> do. I fail to see the value of this approach. Could you explain?
>>
>> Yes, the representation is using relative URIs to reduce message size, and
>> the unmarshaller is eagerly resolving those so the JAXB instance will be a
>> fully useable document. The reason is that the proposal is about structural
>> links only, and in our experience, most links are actually followed rather
>> soon. Our test users told us that they rather like to have a document to
>> edit which already contains all references, so they later can drop the LAN
>> cable and use the document locally (our customers are not always online as
>> they are not typical office users but mobile workers). If we would use on
>> demand resolution this would not work obviously but it enforces always
>> online use mode (which is a problem for our customers). Another negative
>> effect of on demand resolution is that the data used by our customers is
>> rather "tightly bound" and the test users didn't like that the referenced
>> data has changed since downloading the master document; they liked it more
>> to have some kind of "weak snapshot", i. e. downloading documents that have
>> more or less the same timestamp. So we developed our application to download
>> eagerly, and on that real world experience we provided the proposal.
>
> OK, it sounds that this is somewhat specific to your use case. Personally, I don't see the advantage of sending links
> and then early getting each of the pieces: it creates multiple connections to get a single entity

+1. Marek

>
>> But I
>> understand that other users might not have that need. BTW, about browsers: I
>> don't know whether it's just my browser, but mine is loading ALL images at
>> once when I open a HTML page. Yours is not? ;-)
>
> Yes, but those are for embedded images like <img src="…"> not <a href="…">. In general, embedding binary data in
> HTML/XML isn't a good idea (hence <img> and MTOM); the use case for structural links is more general than that.
>
> -- Santiago
>