Re: [Resteasy-developers] RESTEasy client changes

[Bill B. <bb...@re...>]

I don't think you need a clustered solution for caching.  Whether on the 
client or on the server.  If we follow Cache-Control semantics, we 
shouldn't need this complication.  With that said, using JBoss Cache 
local-only (Manik has done some serious work here) or something like 
EhCache should be fine.

IMO, I don't think anybody will care about a pluggable SPI if we follow 
strict Cache-Control semantics.  Then again, I don't care how its 
implemented as long as a contributor does the work :)

Ryan J. McDonough wrote:
> Hey Bill,
> 
> I have been thinking about this and following this thread. First off, I 
> would not like to see a cache solution work with a single API. For some 
> folks, JBoss TreeCache may not be an option and some larger clients may 
> want to leverage existing caching solutions. I can envision the scenario 
> where an application could utilize a clustered HTTP cache but also 
> require something small and sweet. I'd like to be able to be flexible 
> while being able to accommodate HTTP caching properly. If we would have 
> to implement our own logic to accommodate a per-resource expiry, I don't 
> see it as necessarily a bad thing. It's just more work ;). My current 
> thinking is that we create some type of pluggable SPI so that we can 
> take advantage of any caching system. With that said, I'm a bit more of 
> a fan of the "layer on top" of an existing caching API.
> 
> I guess the question is, do people agree on the "layer on top" approach?
> 
> Ryan-
> 
> 
> 
> On Oct 10, 2008, at 9:49 AM, Bill Burke wrote:
> 
>> I know JBoss Cache allows you to define domains based on node-path.  So
>> it might work.  I've pinged Manik on it.
>>
>> Cache-Control is weird though.  You may keep something cached for as
>> long as you like, but you have to validate it with the server.
>>
>> It would be really cool if I could find somebody to look into this
>> (and/or the Spring thing too).  I've been meaning to do it, but I get
>> stuck writing articles and fixing bugs.  TCK work is starting next week
>> too :(.
>>
>> Solomon Duskis wrote:
>>> Bill,
>>>
>>> Yeah, I understand the protocol well enough...  The problem is chosing
>>> an cache implementation technology.
>>>
>>> RESTful caching requires per-resource value for "max time to live"
>>> because each URL can have a different value.  You'll definitely need a
>>> wrapper object to store ETag info; however, it would be nice to use the
>>> caching technology's expiration/eviction settings rather than having to
>>> build that yourself.
>>>
>>> All of the caching technologies I've seen, except for memcached, have a
>>> per cache setting for "max time to live" (determined by an XML file, or
>>> programmatically).  Memcached allows you to set a timeout per cached
>>> instance rather than per cache, but you probably rule out memcached
>>> because a purely distributed cache system seems like a totally wrong
>>> solution for a RESTful client.
>>>
>>> Unless I'm mistaken, you'll have to either modify a caching technology
>>> to allow a per instance timeout (which I assume you can do with your
>>> pull with the JBoss caching team, Bill), or to write a layer on top of
>>> an existing solution that manually checks max-age/Expires values in
>>> order to do expiration.
>>>
>>> -Solomon
>>>
>>> On Wed, Oct 8, 2008 at 4:33 PM, Bill Burke <bb...@re...
>>> <mailto:bb...@re...>> wrote:
>>>
>>>    <snip>
>>>
>>>
>>>
>>>        As far as the caching client goes: I'm not quite sure which
>>>        existing caching solution best fits a RESTful request.
>>>
>>>
>>>    Read up on Cache-Control header.  Basically the server passes a
>>>    response header that states the cache policy.  Its a pretty rich
>>>    protocol.
>>>
>>>
>>>    --
>>>    Bill Burke
>>>    JBoss, a division of Red Hat
>>>    http://bill.burkecentral.com
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win 
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the 
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com