The HTTP toolkit requires the introduction of object methods to the Daylight toolkit API. In the HTTP toolkit these serve as callbacks, but methods may be used for many other purposes also. In it's current implementation, the HTTP toolkit defines five such methods as HTTP object properties (_init, _loop, _beat, _error, _exit). Of these, only one (_loop) is needed for basic operation.
Something that ought to be part of the HTTP protocol, but it doesn't seem to be, so it was invented as part of the HTTP toolkit. A service domain is simply a set of IPs which an HTTP server will service. It may be a network or a list of IPs. The default service domain is the server's own (A-, B-, or C-class) network, but it can be set like any other HTTP object property to, for instance, a subnet or www. HTTP requests originating from outside the service domain get a 403 Forbidden response.
Data from posted forms are available as a sequence of name-value pairs as the _posts request property.
Multipart encoding is supported to allow file upload from the client's machine. Data is provided as a normal posted property _value. Additionally, the "_filename" property is defined.
Netscape cookies are supported to provide a limited amount of state information. Default or user-provided encryption is supported.
HTTP 2.0 challenge/authentication protocol is supported.
The first use of the HTTP toolkit will be to create Daylight application programs. We can provide a complete replacement for DCGI (something we've never fully supported due to it's shortcomings). The HTTP-toolkit based DCGI replacement should be superior to in performance, robustness and supportability. Is everyone OK with a straight replacement strategy?
The HTTP toolkit is designed with the idea that the toolkit itself will be a product, much like the other Daylight toolkits. It's not tremendously chemistry-oriented though ... should we release/support it as mainstream Daylight software? If so, should we do so right away (i.e., with the first release of Daylight HTTP-oriented servers)?
It's tempting to build a bunch of chemistry-oriented utilities right into the HTTP toolkit. For instance, it's trivial to deliver Grins.jar which provides robust JavaGrins access to all programs using the HTTP toolkit. What makes sense to build-in, what to make a separate service? File format conversion? SMILES canonicalization? Eventually it'll grow fat. On the other hand, it all lives in a shared runtime library. Humm.