Re: [Resteasy-developers] RESTEasy client changes

[Ryan J. M. <ry...@da...>]

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