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