Resent, reply to all... 2010/10/9 Michael Lucas-Smith <michael.lucassmith@gmail.com>:
Hehe, I've got the feeling to surf on your hard work with low investment ;) Xtream ideas should definitly continue to attract. J'espère que la mayonnaise va prendre. Of course the best option is to share. Though I don't think Xtream was developped with portability as main goal, it's not sure it has so many external dependencies. Is there a tool to identify the dependency on classes outside the package in VW ? We know in advance a few concerning the system, File & Sockets, DLLCC, compression... With good package delimitation, that can be worked out.
We divided the Xtreams packages up with this in mind. The Core should be portable, the Terminals are not -- they must be implemented for each platform because they're the ones that use the platform specific objects.
I'm browsing VW right now, at first sight there are not so many uncompatibilities in core, should be solved easily Incomplete>>#raise could be added (#signal in Squeak) #copyEmpty: could be an extension #isFixedArgument not existing in Squeak (external heap notion exists though) Lack of namespace in Squeak shall force use of a prefix (XT ?). Some terminals are generic and should port easily too: BlockClosure/Buffer/Collection For File, assuming they are non blocking, we can arrange a quick hack. For transforms, the StreamEncoder does not exist in Squeak (better not use existing Multilingual, a rewrite will be cleaner).
The problem with Squeak is that we don't have a good File library (non blocking). The good point with Xtream is that we don't need that many primitives. And last good point is the huge effort you made to coverage tests... That should ease porting.
It's okay if not all terminals and transformation are supported on every platform. We could create a capabilities grid for the different ports to show what can and can't be done.
Then, there is the question of using Exception handling or not. In Squeak, this isn't going to be a matter of compatibility (though the difference might be subtle), rather a matter of efficiency. However, Incomplete is a corner stone of Xtream implementation if I understand correctly... Squeak is not using EndOfStream http://bugs.squeak.org/view.php?id=6755 and some of the efficiency reasons are there http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-November/122434....
Even in VisualWorks Exceptions are expensive. We went to great lengths to make sure the exception mechanism did not fire constantly. We spent several agonizing weeks studying the effects of our implementation on garbage generation and efficiency until we finally arrived at the design we have now. The biggest problems were with substreaming which we eventually solved.
Michael
The simplest thing is just to port a few classes then bench... That's worth a try. Nicolas