Gemini Networking Layer

Last updated by Rick Potts on 1/26/98


Gemini needs to use the same networking paradigm as Gromit to allow easy integration. It is unlikely that Gromit will abandon its current asynchronous push networking model provided by NetLib-1.


  1. Repackage the NetLib code into a stand-alone component which is shared by both Gromit and Gemini.
  2. Move the network processing performed by NetLib onto its own thread(s).

  3. This allows other threads to receive data even when the UI thread is blocked
  4. Allow streams to process the pushed data either on the NetLib thread or to marshal it onto the requesting thread.

  5. Streams being processed by non-threadsafe code can marshal the data to prevent re-engineering existing code.
  6. Create new APIs providing synchronous URL loading which can be used by newer code (such as java) that runs on different threads...
  7. Incrementally shore up the NetLib code so it is more maintainable and efficient over time...


  1. Repackage NetLib as a stand-alone component. This requires defining a strict public API which will isolate the underlying implementation from its consumers.
  2. Deal with threading issues and requirements.
  3. TBD...


  1. Exposed or shared data structures:
  2. Threading...

Functionality provided by the current NetLib-1:

  1. Networking engine which loads URLs for the following protocols:
  2. Proxy support (what does this involve?)
  3. Maintains stream converters and decoders for MIME type conversions.
  4. Memory and disk cache support.
  5. URL parsing utilities.
  6. Asynchronous DNS lookup
  7. Hooks for global history.
  8. Hooks for network progress notifications.
  9. Other stuff ?

Overview of current NetLib-1 operations

In NetLib all URLs are loaded asynchronously. A URL load is started by calling NET_GetURL(...) which places the request on the net_EntryList or on a wait queue if there are too many active connections. URL loads are driven by repeatedly invoking the NET_ProcessNet(...) function. NET_ProcessNet(...) walks the net_EntryList and reads any data available for each ActiveEntry. This data is ultimately pushed out the associated stream via calls to the stream's put_block(...) function.

Netlib also maintains lists of converters and decoders which provide stream factories for various MIME types. Whenever a stream is created these lists are consulted to determine the appropriate type of stream to create for given data...