[infinispan-dev] [ISPN-78] RFC: Finalizing API

Manik Surtani manik at jboss.org
Wed May 18 07:19:57 EDT 2011


On 18 May 2011, at 12:07, 이희승 (Trustin Lee) wrote:

>> 
>>> And finally there is that eternal question of how to properly name those 
>>> interface methods. Trustin has expressed his concern that 
>>> writeToKey(...), removeKey() and readFromKey(...) might fail to convey 
>>> their semantics. And indeed there's nothing in their names to tell a 
>>> user that they deal with large objects. What about alternatives á là
>>> 
>>> - void storeLargeObject(K key, InputStream largeObject) or 
>>> putLargeObject(K key, InputStream largeObject)
>>> 
>>> - OutputStream newLargeObject(K key) or simply OutputStream 
>>> largeObject(K key)
>>> 
>>> - InputStream getLargeObject(K key)
>>> 
>>> - boolean removeLargeObject(K key)
>> 
>> Suggestions above are good; here are a few more choices:
>> 
>> void storeFromStream(K key, InputStream is);
>> OutputStream openStreamForWriting(K key);
>> InputStream openStreamForReading(K key);
>> boolean remove(K key);
> 
> In addition, don't we need to expose some meta data like the size of the
> stream (if the underlying store can provide that)?  Are we going to
> leave it as a responsibility of the client? (i.e. storing metadata as
> additional non-stream entries)

Yes, some form of MetaData would need to be defined.  Or maybe we just need size.

int sizeOfEntry(K key)

> I also was wondering about the use case where a client retrieves a
> fragment of a stream (i.e. ranged retrieval), but I guess it could be
> done with lazy InputStream with proper skip() implementation.  Correct?

Yep.

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

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






More information about the infinispan-dev mailing list