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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Olaf Bergner
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.

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.

Thoughts?

Cheers,
Olaf


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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
[hidden email]
twitter.com/maniksurtani

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




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev