[Seaside-dev] Help with stream portability

[James Foster]

An idea! Since GemStone does not (yet) have a ReadWriteStream class  
(as it should to comply with ANSI), I could add ReadWriteStream and  
give it the correct behavior. This should not have any backwards  
compatibility issues since the class did not exist. The remaining  
issue is whether the new tests for ANSI stream behavior would be  
willing to use (WAPlatform current readWriteStream) instead of  
explicit references to the classes (which, of course, should work per  
ANSI).

James

On Jan 26, 2009, at 3:25 PM, James Foster wrote:

> All,
>
> As you may be aware, I'm trying to port Seaside 2.9 to GemStone. In  
> general things are going well. I've made a couple false starts but  
> been set straight pretty quickly in most cases. Thanks for all your  
> help and patience. Right now I've got Seaside-Platform pretty well  
> ported and tests mostly passing in GemStone. I'm now working on  
> Seaside-Core and have things cleaned up enough in Squeak so that  
> there is only one test failure--and it is expected. Moving this to  
> GemStone has surfaced an issue that looks to be a challenge. I'm at  
> a point where I would appreciate some help on a direction to go.
>
> Since the beginning, GemStone has implemented streams with  
> 'position' identifying the next object rather than the previous  
> object. That is, (ReadStream on: 'abc') position = 1. I'm a strong  
> advocate for ANSI compatibility (one of my major triumphs was  
> getting ANSI Exceptions into GemStone), and I've entered a GemStone  
> bug to document/track this issue.
>
> Obviously it would be trivial to modify #'position' and #'position:'  
> to add/subtract the internal value by one before answering.  
> Unfortunately, we also need to consider existing code and customers  
> and preserve backwards-compatibility and hence the dilemma. I see  
> four options:
> 	1) Fix GemStone;
> 	2) Have GemStone run a forked version of Seaside;
> 	3) Create and use a portable method (e.g., #'ansiPosition' or  
> #'positionA'); or
> 	4) Refactor Seaside code so that it does not use these methods.
>
> I don't think I'll be successful in #1 in the short-run and I'd very  
> much prefer to avoid #2. I'd be happy to implement #3, but that  
> would create a burden on other dialects to add this method. To  
> determine the scope of this problem and the cost of #4 I've done a  
> bit of investigation.
>
> Based on my review of the Seaside code (Seaside-Platform through  
> Seaside-Environment), I found no (non-test) senders of  
> Stream>>#'position:' and only one sender of Stream>>#'position'. The  
> single sender of #'position' was WAEncoder class>>#'initializeBMP'  
> and the test for the size of the stream contents was trivially  
> refactored to use #'size' instead.
>
> There only remaining references were both added recently to test  
> Stream for ANSI compatibility. Given that Seaside does not send  
> these messages (as far as I've been able to determine), I wonder if  
> we could create a new package, ANSI-Tests, to hold tests for  
> platform behavior that is not needed by Seaside. Philosophically,  
> I'd very much like to have all the tests pass. If there are tests  
> that specifically point out failures in unnecessary functionality,  
> it would be nice if they could be isolated and expected to fail.
>
> Any suggestions?
>
> James Foster
>
> P.S. Apologies if this arrives twice. The first time I sent it was  
> from an email address that is not subscribed to the list.
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>