-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter,
Peter Kennard wrote: > In some sense yes, but then almost all uses of HTTP are doing this to > one extent or another because initially HTTP was so shallowly > conceived. Actually, I completely disagree. I feel that HTTP has withstood the test of time in spite of the evolution (and revolution) through which it has been put. You want to use HTTP like telnet. It just doesn't work like that. You can /make/ it work like that by using perversely long keepalives and streaming responses to the client instead of just sticking to the request/response model which is pretty much a core feature of the protocol. Detecting the last chunk of incoming data isn't something that is useful if you are using HTTP. How do you know that the client is finished with the connection? It sends a "connection:close" header with the last request -- assuming you are using keepalive. The HTTP spec does not appear to provide any standard way to detect the "last" chunk, anyway (except for trailing headers). How would you propose that Tomcat (or any server) detect the last chunk for you? If you want to implement trailing headers yourself, you are free to do so and Tomcat will not prevent you from reading them yourself. I'm sure that the Tomcat team would accept a patch, or at least be interested in hearing your ideas for additional features to support chunked encoding, but I'm sure you'll get a lot of questions regarding the universality of such support. > Tomcat already has built a very good, administrable server side > application structure, packaging scheme, remote deployment system, > developer administration and access scheme, application manager web > ui, and a "standards based remote platform independent UI system" ie: > HTTP1.1 support + jsp + libraries for use of the web desktops. I would have said "application server", but that's just me. Note that Tomcat is a web application server (i.e. HTTP). It was not intended to be a general-purpose server platform. This reminds me of a P2P software group that built their client into Mozilla Firefox mostly because it has a useful API available to it. They claimed to see browser integration as some kind of requirement, but it became evident that they just didn't want to write more code than necessary. They complained to no end about the lack of support for tray icons and background notifications in the browser and wrote all kinds of nasty hacks to make their client act more like a P2P client application /should/ work, but what they were really doing was backing themselves into a corner. They didn't want to write network code, so they ended up writing tons of other support code to subvert Firefox instead. - From what I've read, you have a system to deploy, not just one application. Certain aspects of your system really lend themselves to being served by Tomcat: the web-based parts. So, use Tomcat to deploy your web stuff. Write a separate server to handle this special-case stuff. If you want a streamlined protocol that meets your needs and does everything you want it to do, then just make up your own application-specific protocol. Networking code just isn't that hard to write. > And if I remain AJP complient internally I can take advantage of load > balancers and a lot of other "off the shelf stuff". This includes > all the O'Reilly books and documentation, and the pool of available > personell who know how to use it, etc. (and this list BTW), I can > hire people and with an API supported by a subclass of Servlet, > integrate them in with IDE support, eclipse plugins etc to work on > creating multiple modules quickly. Except that everyone will have to learn all about the odd protocol that you are using with HTTP. You are basically tunneling your own protocol through HTTP. That's actually a reasonable thing to do. Just don't expect HTTP to change because you can't tunnel your own protocol though it flawlessly. What good is the servlet API when you have to basically throw it away to get your "real" work done? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7DZU9CaO5/Lv0PARApKMAJwP1pXTELdvuFxj0NF4AfUpmkl3LgCdEh/p 1/f1ml6CNAAq1aqHueLRRHw= =/YHb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
