Frank Bergmann wrote: > Hi Jeff, > > > Perfect, thanks a lot, I pretty much agree with your view. > >> SPDY and WebSockets > > I may underestimate the importance of these protocols. I > believe I haven't every heard about a real-world application > using these protocols. I would be interested to hear the > opposite.
SPDY should be completely invisible: if the browser and server support it then things will just get faster; theoretically it could improve page load times by 50%, but some people have suggested it could be much less than that. Still, faster is faster. WebSockets is an application tool, can do the same things as AJAX but with a lot less overhead. Expect to see more of it as it becomes more standardized and widely available. > Anyway, these are probably add-ons with little impact on > the stability of existing functionality, so that should be > "mostly harmless". Yep, that's the plan. >> shiny new feature > > The most shiny features that I see in AOLserver/NaviServer > are in the area of scalability and reliability. I'm a fan of flexibility, personally. But even though web/application servers are infrastructure, there still are things that come up that might not be especially new in what they're doing, but in how they are delivered. And having certain features in the infrastructure can greatly simplify deployment of these things. A case in point is google's mod_pagespeed for apache. It does a handful of transformations to the output of the web app, coalescing javascript files, changing css to be inline, etc. These things are not difficult to do to a single page, new application, or well-templated system, but can be quite time-consuming to do to thousands of webpages across unrelated systems. How well this all works may be debatable, but say "google likes it" and you instantly get the attention of certain people. This kind of post-application filtering was the motivation for Ns_ConnGetResponseContent and Ns_ConnSetResponseContent and the pre-write filter - it allows a way to look at and change the data being sent to the user after being generated and before being sent. Being able to do it in tcl makes it very easy to work with and flexible. And flexibility breeds interesting new uses; for example I realized that this could be used to implement full-page caching within the server with fine-grained control over expiry, without touching any other application code. It's almost like putting varnish in front of your server, but without another deployment headache. >> ]po[ > > We've thought a bit about what we (]po[) expect from a new > version of AOLserver. The truth is: not much (for the core > of ]po[). Just please continue with Win32 and fix the memory > bloat issue in 4.5.1 (or recommend an appropriate TCL version > or whatever). Can you give more info on the bloat problem? Or point to other threads, etc.. > One last comment: > Is it really necessary to have separate AOLserver and > NaviServer versions? The community is already small and now > there are (partly?) redundant efforts. I think it started with a suggestion list something like what I posted, but at the time AOL still employed most of the core developers and there was internal pressure there (I'm guessing mostly for api stability) that was at odds with the desires of the OSS community who wanted more radical and incompatible changes to be considered. Since then AOL has "downsized" that tech group and has no more interest in the project, so such a split would probably not happen today. Could the two be re-merged? Possibly. It's worth talking about. [Sincere apologies to anyone who was directly involved if I got the details wrong] -J ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
