On Fri, Oct 2, 2015 at 8:06 AM, Chris Cunnington <brasspen at gmail.com> wrote:


> I do not have a mental model for what Xtreams is doing yet. How do other
> people conceptualize using Xtreams in contrast to the existing Streams
> implementation?
>

I think the elegance of Xtreams boils down to one thing: composition is
better than inheritance.

If you look at the Squeak stream hierarchy, it's a nightmare. Among the
highlights:


   - There's a whole subhierarchy dedicated to compression. It successfully
   shares code for different types of compression but since DeflateStream
   inherits from PositionalStream, it can only write compressed data into
   memory. If you want to write compressed data to a file, you'll have to
   write to a compression stream, get its contents and write that to a file
   stream.
   - On the flip side, there's CrLfFileStream, which converts line endings
   when reading and writing to a file. Except wait, it's obsolete now
and CrLfFileStream
   new actually returns an instance of MultiByteFileStream. This class has
   an annoying name, because it's camel-cased on syllable boundaries as well
   as word boundaries. Ugh. Worse, it combines line-end conversion with
   encoding conversion, but only when it text mode. Well, most of the time,
   when in text mode. You gotta be careful about those few methods that
   manipulate the file position in terms of bytes, because that can leave it
   in the middle of a multibyte character and then nothing works right. And if
   you want to do any of this conversion on data in memory, you're outta luck
   because MultiByteFileStream only works on data in files.
   - Luckily MultiByteBinaryOrTextStream is here to save the day. (Again
   with the capitals on syllable breaks.) It *does* work on data in memory. It
   has a whole separate implementation of the encoding and line-ending
   conversion code, plus no-nops implementations of the file-related
stuff in MultiByteFileStream
   so the two are polymorphic. So convenient.
   - There's also ReadWriteStream, which subclasses WriteStream, and
   re-implements all of ReadStream's functionality.
   - There's also SocketStream, for convenience in doing network IO. Oh
   wait, it's not part of the Stream hierarchy at all. Never mind.

There's more (lots more), but let's not get sidetracked. The point is that
there is just no way to have a sane inheritance hierarchy for a whole bunch
of orthogonal concerns:

   - the underlying data storage - memory, file, socket or something more
   exotic
   - data transformation - encoding, compression, buffering, chunking etc
   - reading vs writing

Where Squeak streams try to do everything in one object, and combine
different options via inheritance, Xtreams splits a stream into a pipeline
of objects that each provide a separate bit of functionality. It's so much
more flexible.

In the specific case of Altitude, Xtreams provide two main advantages:

First, the framework can build a custom pipeline of streams based on
message headers. To handle a request, we just examine the headers, build
the appropriate sequence of transformation streams and hand that off to the
application for reading. When the response is ready, we again look at the
headers, build a stream that performs all the transformations that the app
has indicated it wants, and let the app write into it. We can use any of
the features of HTTP, while still providing a simple and consistent
interface to the app.

Second, it really helps with perceived performance. Browsers have
incredibly optimized strategies for processing data as it arrives from the
network. They're really good at rendering a page incrementally, adding
content and refining the appearance as more data arrives. Xtreams allows
Altitude to take advantage of that by doing the same thing on the server
side. As the app is rendering content, we push it through the
transformation streams in small chunks, and get it on the network as
quickly as possible. (ALStreamingExample is a good demo of this.)

Of course, there's a lot of other little details to like about Xtreams, I
think composition is what really makes it shine.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20151002/cd8b2439/attachment.htm