VisualWorks Parcels

Okay, here are the goods.  To load them into a clean VW 5i.4 image, do this:

- Remove the Swazoo.p* files that come with VW 5i.4.  They'll goof up
the load.
- Unzip this archive into your image folder (or wherever you'd like to
see it, so long as it's in your parcel path)
- Tools > Load Parcel Named... Swazoo-VisualWorks
- Tools > Load Parcel Named... Swazoo-Tests

----

These parcels include several merges from the SW-Spray (Dolphin Swazoo)
code (including support for HEAD and the ability to merge header fields)
and from eFinNet (including support for PUT and nicer error handling in
the HTTPConnection).  I've also added the following:

- There was a serious security problem in the FileResource; it'd happily
take '..' as a valid path element.  That means that any file on a Swazoo
system could be accessed and transferred with something like
"http://www.reasonability.net/../../../../etc/passwd".  Ouch.  Most
browsers won't let you send this kind of request, but our server would
happily take it if it came in on the socket.

- We no longer implement Number>>asString.  We don't need it anymore.

- Tests have been added for a couple of our base extension methods
(CharacterArray>>trimBlanks and String class>>newRandom:).  Also,
#newRandom: should now work on systems other than my own -- you don't
have to go roll your own SequenceableCollection>>random anymore.  :)

- The Swazoo-VisualWorks parcel overrides the 5i.[34] #trimBlanks,
because the VW version doesn't trim all separators (e.g. CR/LF), and we
rely on this in our reading of multipart form data.  The
multipart/form-data parser is quite nasty; it works, but I wouldn't
complain if it got gutted and re-written (and ended up not depending on
#trimBlanks in the process).  :)

- There were a few method renames / refactors in HTTPConnection and
HTTPResponse for clarity with the new HEAD code.  These look a little
like the SW-Spray code, but the methods got pushed around a little bit.

- Resource tests are no longer a subclass of ResourceTest.  There seemed
to be little point in re-testing the concrete classes once the abstract
class has been tested, especially now that the resources are less
involved in the process of URI resolution than they used to be (and most
of the inherited tests were broken anyhow).

- Perhaps more that I've forgotten by now.

Anybody running VW 5i.4, please let me know how these work for you.  And
are people still interested in a public StORE for Swazoo?


Ken Treis
[hidden email]

Hi Ken:

Two questions:

1. What version of SUnit are you using?
2. Is there a class LogFile that should have been included?

Some comments:

The work you've done looks very solid.  For porting purposes, I think there
is  something that could be improved.  There are several methods that use
literal byte arrays.  They are specified using VW-specific syntax instead of
more standard instance creation methods.  I changed this when doing the
GemStone port.

The GemStone port is progressing.  I started over with the latest code and
have all classes and methods in GemStone.  The only one that I haven't been
able to "gemstone-ize" yet is #connectedPair.  On the whole, I am very
impressed with both the completeness and the conformance to standard of the
GsSocket class.  In particular, the method naming is lucid.

BTW - Does anyone know if there has been any progress getting Wiki as a
resource under SWAZOO?

On Friday 28 September 2001 11:03 pm, Ken Treis wrote:
--
Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

Joseph Bacanskas wrote:

>1. What version of SUnit are you using?
>
I'm using Camp Smalltalk 3.0; it's what came with 5i.4.

>2. Is there a class LogFile that should have been included?
>
Whoops, I missed that one.  I had put some debugging code in
HTTPServer>interactWithNewConnectionOver: back before I moved to 5i and
the new socket code.  Since those two major changes, I've never hit that
exception.  But then again, I haven't really stressed the new code like
I have the old VW3.1 code (Signal Ground was quite a stress, it more
ways than one).

So while I'm not entirely comfortable taking the exception handler out,
I'd be more than happy to change that LogFile stuff in there to a
Transcript>>show:.

>Some comments:
>
>The work you've done looks very solid.  For porting purposes, I think there
>is  something that could be improved.  There are several methods that use
>literal byte arrays.  They are specified using VW-specific syntax instead of
>more standard instance creation methods.  I changed this when doing the
>GemStone port.
>
Okay, I'll try to hunt those down in my code, too.  Did you use
ByteArray>>with:with:with: and friends?

>The GemStone port is progressing.  I started over with the latest code and
>have all classes and methods in GemStone.  The only one that I haven't been
>able to "gemstone-ize" yet is #connectedPair.  On the whole, I am very
>impressed with both the completeness and the conformance to standard of the
>GsSocket class.  In particular, the method naming is lucid.
>
Good deal.  #connectedPair is used by the tests, but Swazoo itself
doesn't need it.

My ideal is that all methods in the Swazoo and Swazoo-Tests parcels
should load straight into GemStone (and any other Smalltalk).  That way,
if base code changes, you can just import it into GS; the GS-specific
stuff wouldn't have to change.  So please let me know if there are any
other problematic methods.

Along those same lines, how much would it goof up your process if we
pushed everything into a "Swazoo" namespace?  I'm looking at putting
Swazoo up on the Cincom Public StORE, but I'd like to do the namespacing
first if at all possible... just so we play nice with everybody else on
there.  ;)

>BTW - Does anyone know if there has been any progress getting Wiki as a
>resource under SWAZOO?
>
I haven't heard anything from Ramneek lately.  I think it'd be a simple
task to get a basic Wiki running under Swazoo, but supporting all of the
WikiWorks functionality might be a little more involved.


Ken

Hi Ken:

Concerning portability to GemStone, etc...

I discovered the LogFile when I attempted to move the
HTTPServer>interactWithNewConnectionOver: method into GemStone.  It failed
because there was no class/global LogFile.

The major areas of mismatch between VW and GemStone from a Swazoo perspective
are:

1. GemStone does not implement a SocketAccessor class.  However, GsSocket
implements the stream protocol, so the substitution was fairly
straightforward.  Also, IMHO, the GemStone  messages seem to be named better
than the VW ones.

2. GemStone does not deal with files the way VW does.  There is no Filename
class.  GsFile (like GsSocket) inplements the stream protocol.  In many ways,
the GsFile implementation is much more obvious and intuitive.

3. Literal declarations of ByteArrays do not exist in GS.  either
#with:with:with:, etc or #withAll: aCollection are substituted.  Since both
VW and GS implement #withAll:, we could just do something like
ByteArray withAll: #(6 5 4 3).  That is what I did.

4. Of course, GemStone is headless, so Transcript show: and friends won't
port unless you do some fancy footword in GS.

5. GemStone implements DateTime while VW implements Timestamp.  This is a
fairly easy substitution when you move the method in.

6. GemStone exceptions have 4 arguments while VW only has one.  VW has many
subclasses of Exception, GemStone has a pair of persistent Exception
Dictionaries.

7. GemStone does not implement some of the non-ANSI "shortcuts" for stream
creation.  This is not a big deal.

8. Except for a tool that I don't have yet, there is NO version control for
methods, nor is there a way to compare method changes, so please, don't
change anything until I can get working code posted. (just kidding on the
don't change part).

9. There are some differences in String superclasses that can confuse things.

That's all I can remember at the moment.  I am using the porting process to
introduce one on my colleagues to the differences between client Smalltalk
and server Smalltalk.  Swazoo is a great intro for that. ;-)

At this time, there is no need to change base code to get closer to something
loadable in GemStone.  Just like with SUnit for GemStone, I hope to get a
parallel version 100% working and then just keep them in sync.

Cheers!!

On Saturday 06 October 2001 11:33 am, Ken Treis wrote: there
> >is  something that could be improved.  There are several methods that use
> >literal byte arrays.  They are specified using VW-specific syntax instead
of
> >more standard instance creation methods.  I changed this when doing the
> >GemStone port.
> >
> Okay, I'll try to hunt those down in my code, too.  Did you use
> ByteArray>>with:with:with: and friends?
>
> >The GemStone port is progressing.  I started over with the latest code and
> >have all classes and methods in GemStone.  The only one that I haven't
been
> >able to "gemstone-ize" yet is #connectedPair.  On the whole, I am very
> >impressed with both the completeness and the conformance to standard of
the
--
Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.