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

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(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev