Brian and I talked privately about changing CacheLoader API to use object based stream parameters rather than plain input/output streams. Please comment. -----Original Message----- From: Brian Stansberry Sent: Saturday, August 26, 2006 2:29 PM To: Vladimir Blagojevic Subject: RE: Stream dilemma I much prefer the latter. Earlier on a thread about this we determined we wanted cross-CacheLoader interoperability and thus were going to formally specify the format of the state as a sequence of serialized NodeData objects. Therefore by the interface contract the cache loader must use an ObjectInput/OutputSteam to do its job; it's not like the loader implementor has freedom to use some com.xyz.CustomStateEncodingInput/OutputStream. Given that, providing the ObjectInput/OutputStream to the cache loader makes a lot more sense for the reasons you stated. The CacheLoader's job is simply to read the objects and store them; it shouldn't have access to the stream underlying the ObjectInput/OutputStream as providing that access limits the flexibility of the StateTransferGenerator/Integrator. Once you provide the ObjectInput/OutputStream, that also logically implies that the overloaded methods with the byte[] should go away. Either the CacheLoader has to know how to manage the lifecycle of an ObjectInput/OutputStream or it doesn't. Vladimir Blagojevic wrote: Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat Ph: 510-396-3864 skype: bstansberry