[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