[oslc-core] Issue with Compact Rendering of a deleted (410) resource

[Steve K Speicher]

Hi Mike,

Appreciate you raising this discussion on this list.  It helps show what 
implementers are running into and what they need to consider.

To spell out your failing example in detail, it might help the "race" 
condition that an implementation might get into:

1. Client fetches oslc:Compact resource representations at some URI say 
http://example.org/thing and gets a 200-OK
2. Someone deletes the corresponding oslc:Compact resource at 
http://example.org/thing
3. A client gets a 410-Gone if attempted to access the resource at 
http://example.org/thing
4. A client has already received a valid oslc:Compact representation (step 
#1) and parses out the URL from the oslc:smallPreview XML element's 
@rdf:resource as 
http://example.org/preview?view=small&resource=http://example.org/thing
 4a. Client then goes to present the preview by creating an iframe setting 
the @src to the URL from the previous step
      Since http://example.org/thing is delete but the implementation GET 
request asking for HTML using URL 
         
http://example.org/preview?view=small&resource=http://example.org/thing
       It is this implementation's response to return appropriate message, 
right?
       A client could be really careful and preform a HEAD on 
http://example.org/thing to verify the resource is still there

This leads me to believe that this is not a spec issue but is an 
interesting condition that would be good to highlight in some implementers 
guide.

Does this make sense to you?  Anyone else have any additional thoughts?

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: Michael A Jaworski/Durham/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 09/23/2011 01:45 PM
> Subject: [oslc-core] Issue with Compact Rendering of a deleted (410) 
resource
> Sent by: oslc-core-bounces at open-services.net
> 
> Hi all,
> 
> I'm seeing a problem with the widget that controls the compact rendering 
of 
> a resource (rich hover), specifically after the resource has been 
deleted. 
> There are two scenarios that I've encountered that exhibit different 
behavior:
> 
> 1) Acceptable case: If the resource is deleted before the compact 
document 
> is fetched, the widget properly recognizes the 410 code returned by the 
> server and disables the rich hover on any following attempts, also 
> displaying a message which says, "More information is not available". 
(See 
> Image1.jpg attached)
> (See attached file: Image1.jpg)
> 2) Failing case: If the resource is deleted after a compact document has 

> been previously fetched, the widget appears to ignore the 410 status 
> returned by the server and attempts to render the compact document again 

> (which instead just displays a nasty 410 exception in plain text). (See 
> Image2.jpg attached)
> (See attached file: Image2.jpg)
> 
> From a server standpoint, our best course of action is to display this 
nasty
> exception with as pretty language as possible, but I don't think that's 
> going to be acceptable in the long run. Is this a problem with the 
current 
> spec? I would appreciate any insight as to why this happens, and whether 
or 
> not a defect should be filed for this.
> 
> Thanks,
> 
> Mike Jaworski
> Rational Requirements Composer - Server Development[attachment 
"Image1.jpg" 
> deleted by Steve K Speicher/Raleigh/IBM] [attachment "Image2.jpg" 
deleted by
> Steve K Speicher/Raleigh/IBM] 
_______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net