RE: [PROP] Socket Portability Classes (was Re: Taking Swazoo Forward [Long])

> Looks good to me.  Also remember that the Resource name wasn't
> Dolphin-friendly.Are the ObjectMemory references basically used to
> force socket finalization when you're closing down Swazoo cleanly, so
> you can restart immediately?  Perhaps they are used to hook image
> startup/shutdown as well?   I don't remember and my VWNC image is at
> work. I think it would indeed be a good idea to isolate those sorts of
> things into their own object.   We should list the services required
> from an object such as this and design the protocol from there.
> SiteRegistry is already there, but doesn't feel right for these sort
> of grungy and very implementation specific details.   Unfortunately, I
> can't think of a good name for the object right now. ***Here's a quick
> design problem that those of you who are more experienced can help me
> with: Assume we go with AbstractSwazooSocketServer, with subclasses
> providing implementation-specific behavior.  I don't want to go
> through the VW source replacing occurrences of VWSwazooSocketServer
> with DolphinSocketServer.  What is the best way of dealing with this-
> do you add a new subclass, and also change a method in
> AbstractSwazooSocketServer which would answer the right kind of
> SocketServer? AbstractSwazooSocketServer>>implementationSpecificServer
> ^DolphinSocketServer newHere I don't like the fact that you are
> referring 'downstream' in AbstractSwazooSocketServer's own inheritance
> hierarchy.  Doesn't feel quite right.Maybe you build a
> ServerSocketFactory which does the job?  Or something else?  There's
> probably a pattern for this out there somewhere.***Also, I'm hoping to
> bring the Dolphin port up-to-date this weekend.   Are the VW files on
> SourceForge the most current? Thanks,Jerry
> [hidden email]-----Original Message-----
> From: Ken Treis [mailto:[hidden email]]
> Sent: Saturday, October 21, 2000 5:17 PM
> To: [hidden email]
> Subject: [PROP] Socket Portability Classes (was Re: [Swazoo-devel]
> Taking Swazoo Forward [Long])
>
>
>      Jerry Bell wrote:
>
>     > I agree that keeping the code in sync across platforms may
>     > be a problem.
>     > The Dolphin port is quite behind, but my free time
>     > situation should be
>     > improving soon.  I'm planning to let the current changes
>     > to the VW parcels
>     > settle, and then port those changes to Dolphin.
>     >
>     > Still, there will still be some lag in propagating changes
>     > across platforms
>     > unless we are able to figure out some way to isolate code
>     > that is completely
>     > portable across platforms from code which isn't.  The lag
>     > probably won't be
>     > too drastic, so it may not be worth the effort.  Also, it
>     > probably makes
>     > sense to wait until a Squeak port has been completed, so
>     > that we have 3 data
>     > points as to what bits aren't completely portable.
>
>      After reading this (and a couple of your other messages) as
>      well as doing some Squeak playing on my own, I'd like to
>      propose the following changes to the Swazoo socket code.
>      Hopefully, these should ease portability -- at least as far
>      as the socket layer goes.
>
>      Change 1: Pull the socket-serving code out of HTTPServer.
>      In this scenario, the HTTPServer would instantiate a
>      SwazooSocketServer.  The socket server's job is to create a
>      listening socket, block waiting on it, and evaluate a block
>      -- a handling block, if you will -- with a newly accepted
>      stream as an argument.  Then, the HTTPServer code looks
>      something like this:
>
>      initialize
>          ...
>          server := SwazooSocketServer port: port.
>          server handler: [:stream | self
>      interactWithNewConnectionOn: stream]
>
>      start
>          server startServing
>
>      interactWithNewConnectionOn: aStream
>          conn := HTTPConnection stream: aStream.
>          self addConnection: conn
>          conn interact
>
>      There are parts of this operation that'll be platform
>      specific -- we have to create a new socket, listen on it
>      (this object will encapsulate the serveLoop that's now in
>      HTTPServer), create a new stream, evaluate the handler, and
>      repeat.  Therefore, I propose that we make an
>      AbstractSwazooSocketServer (the name doesn't have to be that
>      heinous) that has as much common code as is possible.  Then,
>      we implement a SwazooSocketServer subclass in each dialect.
>      HTTPServer should then be completely portable.
>
>      I'm not sure how we'd test this -- ideas?  Perhaps we could
>      create internal streams, call the
>      interactWithNewConnectionOn: method ourselves, and make sure
>      that the server appropriately creates new connection
>      objects, adds them to its collection of them, and starts
>      them up.
>
>      Change 2: We do the same kind of thing with our streams.
>      VisualWorks lets you create a readAppendStream on any
>      socket.. while Dolphin has some sort of socket stream and
>      Squeak's sockets don't behave like streams at all (though
>      it's not hard to make them do that -- I've written one that
>      we could use as a starting point).  SwazooStreams would need
>      to do the standard stream operations (most of which could be
>      written in an abstract class), and we'd also make them able
>      to tell you what the IP address of the remote site is.
>      Perhaps we could even put utility methods in SwazooStream
>      class for name resolution if we need them.
>
>      SwazooStream would wrap whatever dialect-specific stream is
>      needed, and most of the methods in SwazooStream would just
>      forward to it.  That gives us a unified interface to the
>      streams across dialects.  We could also make our own
>      protocol for binary puts (e.g. nextPutBytes:, since most of
>      the time we want to spew raw bytes in large chunks) instead
>      of using the VisualWorks binary/text mode flipping.  Heck,
>      we could even add SwazooStream>>crlf, nextLine, etc, thus
>      eliminating the need for the silly LineStream.
>
>      This should be pretty easily testable, too, if we just point
>      the SwazooStream at an internal stream and test the behavior
>      of nextPut:, next:, and the like.
>
>      ----
>
>      All of this is to try to isolate the non-portable parts so
>      that it's easier to keep our different Swazoo ports up to
>      date.  Every Swazoo resource should use the SwazooStream
>      protocol, and then Swazoo apps will at least be portable in
>      that respect.  Other hurdles might include an
>      EndOfStreamNotification (we can probably make SwazooStream
>      handle this), as well as any references to ObjectMemory
>      (doesn't work for Dolphin).
>
>      Thoughts, everyone?
>
>
>      Ken Treis
>      [hidden email]
>