"Mariano Martinez Peck"<marianopeck@gmail.com> wrote:

Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary serializer similar to Parcels. More info in http://rmod.lille.inria.fr/web/pier/software/Fuel

For the moment, we are using the "classic" streams we want to give it a try to XStreams. My knowledge on streams is very little, so if someone can give me a hint I would really appreciate it. What I want to do right now is an adaptor of XStreams to classic stream. I mean, I want to create custom subclasses of XTFileWriteStream and XTFileReadStream that implements the same API from classic streams that we use in Fuel. And the implementations of such methods will do just a "self something" where something is the way of doing that in XStreams.

I'd also recommend generic wrapper for any kind of Xtream rather than subclassing specific terminal. In VW the usual way to create the classic streams is via #readStream or #writeStream, so I'd add something like: XTReadStream>>readStream ^XTClassicReadStream on: self XTWriteStream>>writeStream ^XTClassicWriteStream on: self The "classic" guys would then implement the classic API by invoking Xtreams API on their source/destination. You can even subclass those from the classic ReadStream and WriteStream to possibly inherit some behavior and only implement some core part of the protocol.

So, the following is the protocol we use in Fuel for streams, and what I would love to know is the associated way to do it it XStreams. The left is classic streams, and after the "->" it is XStreams:

*Reading:*

nextNumber: -> ?? nextPutAll: -> write: nextStringPut: -> ?? nextPut: -> put: nextNumber:put: -> ?? nextWordPut: -> ??

*Writing: * nextNumber: -> ?? next: -> read:

It's not as simple, there can be subtle differences. For example in VW it should be something like: next: anInteger ^[ source read: anInteger ] on: Incomplete do: [ :incomplete | IncompleteNextCountError new parameter: incomplete count; raiseRequest ]

nextString -> ?? next -> get

Again, in VW it would be more like: get ^[ source get ] on: Incomplete do: [ :incomplete | EndOfStreamNotification raiseRequest ]

nextWord -> ??

For the specialized element types (Number, String) you can pretty much copy the classic implementations (or even inherit them). Alternatively they seem to fall into a category that we call "interpreting" in Xtreams. What we have is primarily focused on interpreting bytes as various C-types (short, long, float, double,....) for which we have convenient primitives in VW, but the concept can certainly be extended further (the interpretation definitions are pluggable). Unfortunately this part wasn't ported yet from VW. For quick overview you can peek at the end of http://code.google.com/p/xtreams/wiki/Transforms. There's also general marshaling stream available on VW side (built on top of the interpreting streams) which might be helpful example of how one can approach this type of problem with Xtreams. HTH, Martin