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

[Olaf Bergner]

Am 18.05.11 13:19, schrieb Manik Surtani:
> 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);
Sounds good to me.
>> 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)
As of today LargeObjectMetadata already stores a large object's total 
size. In the future it may well hold additional metadata as e.g. mime 
type and possibly arbitrary user defined key-value-pairs. To keep the 
API as stable as possible I rather opt for

Metadata largeObjectMetadata(K key)

instead of dedicated methods for each conceivable metadatum.
>> 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.
Yes, should be possible.
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev