Hi Francios,
To go back to your initial design question, it is probably better to start with the THttpAppSrv component which is by far the most advanced one to build dynamic web application backend.
As the THttpAppSrv is a decendant of THttpServer, it requires the same or even larger amont of rework of base components, IMHO. As I wrote before, if we suppose to leave base components as is, then in order to support websocket connection I need to override important methods of both these components, copy/paste all the http-related code from such methods and interlace it with websocket-related additions. I don't like this approach, because we lose http-code inheritence (if some fixes are made in the base components, they will not be available in the websockets server). The most important limitation of the appoach with THttpAppSrv is the same as with THttpServer: it implies two components to serve clients on different ports (one for web-pages and one for web-sockets). But I'd prefer websockets-server to handle connections on the same (presumably standard) port, as the hosting web-server does. IMHO, this is only possible if websockets-support are built-in into the components themselves. Also, I must say that a web-server (THttpServer) is probably the closest candidate to work with websockets, because app-server seems excessive for most common web tasks. Currently, I have an application, utilizing web-server, and I don't see a reason to transform it into an app-server. Did you receive my codes sent yesterday? As you may see, current approach is very simple in the sense that it uses standard web-server and a custom HttpConnection object with websockets functionality. If the issue with different ports can be treated as unimportant, I'd be happy with this approach. Best wishes, Stan -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be