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.
Repackage the NetLib code into a stand-alone component which is shared
by both Gromit and Gemini.
Move the network processing performed by NetLib onto its own thread(s).
This allows other threads to receive data even when the UI thread is
Allow streams to process the pushed data either on the NetLib thread or
to marshal it onto the requesting thread.
Streams being processed by non-threadsafe code can marshal the data
to prevent re-engineering existing code.
Create new APIs providing synchronous URL loading which can be used by
newer code (such as java) that runs on different threads...
Incrementally shore up the NetLib code so it is more maintainable and efficient
Diagram of the new NetLib threading model:
Repackage NetLib as a stand-alone component. This requires defining
a strict public API which will isolate the underlying implementation from
Deal with threading issues and requirements.
Exposed or shared data structures:
MWContext. This structure is only used for progress notifications
and displaying error messages.
URL_Struct. There is a whole pile 'o stuff in this structure!
I doubt that it is all strictly URL related!
Functionality provided by the current NetLib-1:
Networking engine which loads URLs for the following protocols:
Proxy support (what does this involve?)
Maintains stream converters and decoders for MIME type conversions.
Memory and disk cache support.
URL parsing utilities.
Asynchronous DNS lookup
Hooks for global history.
Hooks for network progress notifications.
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...