On Tuesday 27 November 2001 10:56, Geoff Talvola wrote: > At 08:51 AM 11/27/01 -0800, Mike Orr wrote: > >Is there a reason Webware needs a socket connection between its > >AppServer and a future built-in HTTP server? Or could the HTTP > > server just import the AppServer and run it on its own? Would it > > gain any performance advantagess? Would there be any > > disadvantages, besides not being portable to other HTTP servers?
The HTTPServer that I posted about yesterday does exactly that. It contains a reference to the AppServer and dispatches incoming connections directly to it after doing some HTTP stuff. The AppServer is also running on a separate port and can accept connections from a webkit adapter at the same time the builtin HTTPServer is running. > Interesting question -- do you have the AppServer serve up HTTP > directly, or do you have a separate Python process that accepts the > HTTP request and forwards it using the standard Adapter format? > > Pros of using a single process: > > - it would be faster > - it's easier to manage a single process rather than having to > start up and monitor two processes It's faster, but not by much unless you implement some form of output caching. The main advantage is the ease of management. To start it you simply type: $ webkit -H start instead of the standard: $ webkit start or you can control it via the [HTTPServer] section in the '.webkit_config' file. > Cons of using a single process: > > - you can't restart the appserver without potentially losing > requests while it's restarting; with 2 separate processes the HTTP > server process can hold onto the request and retry until the > appserver has restarted - it makes the WebKit core more complicated > since you're bundling in multiple protocols; by keeping the HTTP > server process separate the core doesn't have to change at all It doesn't neccessarily have to make WebKit more complicated. Adding the builtin HTTPServer to the 'experimental' version of WebKit required no changes to the core. All socket connection dispatching in the 'experimental' webkit is handled via the MultiPortServer class. It binds 'services' to each port it is listening on. In this scenario you'd have an instance of the AppServer class bound to port 8086 and an instance of HTTPServer bound to 8087. The AppServer has two main methods: handleConnection() and handleRequest(). handleConnection() deals with the adaptor protocol and sends the incoming 'raw request dictionary' on to handleRequest(). All incoming connections on port 8086 are dispatched to AppServer.handleConnection(). Connections on port 8087 are dispatched to HTTPServer.handleConnection(), which turns HTTP requests into 'raw request dictionaries' and forwards them to AppServer.handleRequest(). You can have any number of services running on different ports, each talking a different protocol and forwarding requests on to the AppServer. A side benefit of the handleConnection/handleRequest division is that you can chain any number of 'Applications' (in the context of a Multi-Application WebKit) together. You can even flatten the dispatch chain to a single thread-safe servlet bound to the port and achieve very significant performance gains. Tavis _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
