[infinispan-dev] [ISPN-78] Finalising the API

[Manik Surtani]

On 12 May 2011, at 15:41, Olaf Bergner wrote:

> After finishing the first iteration of implementing ISPN-961 - Spring 
> Integration - I would like to turn my attention back to ISPN-78 - Large 
> Object Support. Specifically, I would like to finalise the API before 
> concentrating on the hard stuff, namely locking and transaction support.
> 
> These are the changes I currently envision:
> 
> 1. Introduce a dedicated StreamingCache whereas now we have a 
> StreamingHandler a user obtains via Cache.getStreamingHandler(). A 
> StreamingCache would be a special kind of cache completely separate from 
> org.infinispan.Cache. Users would obtain StreamingCache instances from a 
> CacheManager.

Ah ok, I responded to your previous thread, it is now clear as to how you intend to "construct" a cache manager.

> Rationale: Users will IMHO most likely never mix and match "regular" as 
> well as large objects within a single cache. It is my experience that 
> (well-behaved) applications are acutely aware of the special treatment 
> large objects warrant. I therefore suspect that users will reserve a 
> dedicated cache for large objects anyway. Therefore it doesn't make 
> sense for such a cache to expose an API for "regular" objects.
> Further, we might be able to provide sensible default settings for such 
> large object caches whereas now "regular" and large object caches share 
> the same default settings (since INFINISPAN cannot tell the difference).
> 
> 2. Rename API methods:
> 
>     void writeToKey(K key, InputStream largeObject) -> void 
> storeLargeObject(K key, InputStream largeObject)
>     OutputStream writeToKey(K key)                         -> 
> OutputStream newLargeObject(K key)
>     InputStream readFromKey(K key)                         -> 
> InputStream getLargeObject(K key)
>     boolean removeKey(K key)                                   -> 
> boolean removeLargeObject(K key)
> 
> Rationale: The API should center around large objects, not their keys 
> and method names should reflect this.

Again, I suggested a few other names in your previous thread.  :)

Cheers
Manik
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org