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

Reply via email to