<html>
<head>
<title>
Flow architecture
</title>
</head>
<body>
<hr>
<h1>
<a href="http://netjam.org/flow"><i>flow</i></a> architecture
</h1>
<hr>
1 July 1996
<br>
22 January 2002, 2pm pacific
<hr>
This is a discussion of the eventual architecture of
<i>flow</i> 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. Brief discussions of the classes follow.
<p>
<br>
The primary classes are those of the Correspondent hierarchy:
<pre>
Correspondent
Client
HTTPClient
IdentificationClient
IRCClient
MIDIClient
NNTPClient
POPClient
RemoteFileStreamClient
SerialCorrespondent
VISCAClient
X10Client
SMTPClient
TelnetClient
TimeClient
Server
HTTPServer
IdentificationServer
MIDIServer
RemoteFileStreamServer
TFTPServer
</pre>
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.
<p>
It's straightforward to combine multiple correspondents in an
"application". For example, a mailer would probably use multiple
POPClients and SMTPClients.
<p>
RemoteFileStreamClient and RemoteFileStreamServer constitute a
network file system. MIDIClient and MIDIServer are the beginnings of
the NetJam distributed music system.
<p>
I rewrote the Stream hierarchy:
<pre>
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
</pre>
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.
<p>
The NetMessage hierarchy extends stream protocol to the
creation of email and news messages, minimizing copying.
<p>
External resources are named by Universal Resource Locators
(URLs):
<pre>
URL
HostBasedLocator
Filename
Maildrop
MessageLocator
</pre>
All low-level access to the outside world is factored into one
hierarchy:
<pre>
ExternalResource
File
NetResource
HardwarePort
1394Port
AudioPort
InfraredPort
MIDIPort
ParallelPort
SerialPort
USBPort
SocketAddress
SocketAddressResolver
SpeechRelay
</pre>
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.
<p>
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.
<br>
<br>
<hr>
</body>
</html>