1 July 1996
22 January 2002

This is a discussion of the eventual architecture of flow as I currently imagine it; I haven't released all of it yet. In particular, I envision support for several transports (sockets, files, serial and parallel ports, MIDI, digital audio, firewire, infrared) but so far I've only released support for sockets and files. Brief discussions of the classes follow.

The primary classes are those of the Correspondent hierarchy:


   Correspondent
      Client
         HTTPClient
         IdentificationClient
         IRCClient
         MIDIClient
         NNTPClient
         POPClient
         RemoteFileStreamClient
         SerialCorrespondent
            VISCAClient
            X10Client
         SMTPClient
         TelnetClient
         TimeClient
      Server
         HTTPServer
         IdentificationServer
         MIDIServer
         RemoteFileStreamServer
         TFTPServer

      Correspondent, Client, SerialCorrespondent, and Server do the recurring bookkeeping involved in writing clients and servers. For example, a Server keeps track of the clients connected to it, and has simple default behavior for servicing and disconnecting them. Transport details are encapsulated by NetStreams (described below). Correspondent authors can focus on protocol details, with a streamy message interface, instead of transport details.

      It's straightforward to combine multiple correspondents in an "application". For example, a mailer would probably use multiple POPClients and SMTPClients.

      RemoteFileStreamClient and RemoteFileStreamServer constitute a network file system. MIDIClient and MIDIServer are the beginnings of the NetJam distributed music system.

      I rewrote the Stream hierarchy:


   Stream
      PositionableStream
         WritableStream
            DiscardingStream
            ExternalStream
               FileStream
                  AppendingFileStream
                  AppendingFileStreamWriter
                  RemoteFileStream
               NetStream
                  Conversation (used for speech recognition/synthesis)
                  HardwareStream
                     1394Stream
                     AudioStream
                     MIDIStream
                     ParallelPortStream
                     SerialPortStream
                  SocketStream
                     TCPStream
                     UDPStream
            NetMessage
               EmailMessage
               NewsMessage
            RingBuffer
               InfiniteRingBuffer
            TextStream
         RandomNumberStream

      I was originally motivated by the need to get a filesystem working on custom hardware. The existing Squeak filesystem support (including the Stream hierarchy) was cumbersome, with a lot of unreachable and redundant code and an overly-complicated class factoring. The new factoring is much simpler, unifies all "external" resources with the ExternalStream hierarchy, and has smarter buffering.

      The NetMessage hierarchy extends stream protocol to the creation of email and news messages, minimizing copying.

      External resources are named by Universal Resource Locators (URLs):


   UniformResourceLocator
      AuthenticatingLocator
      HierarchicalLocator
         FileLocator
         Filename
         HypertextLocator
         MIDILocator
      TelnetSession
   MailAddress
   MessageLocator
      MailMessageLocator
      NewsMessageLocator

All low-level access to the outside world is factored into one hierarchy:


   ExternalResource
      File
      NetResource
         HardwarePort
            AudioPort
            IEEE1394Port
            InfraredPort
            MIDIPort
            ParallelPort
            SerialPort
            USBPort
      Socket
         TCPSocket
            ClientTCPSocket
               IncomingClientTCPSocket
               OutgoingClientTCPSocket
            ServerTCPSocket
         UDPSocket
      SocketAddress
      SocketAddressResolver
      SpeechRelay

All external resources support an interface which makes them suitable for use as collections for NetStreams. File will probably have subclasses to account for host platform differences.

Exception handling is used in many places by the classes above, usually for "ensured behavior". For example, one may open a file stream and write to it, ensuring that the file will be closed despite interruptions.