Dear all,
I do not think that removing Windows specific code is a good idea.
Some time ago I showed as example how many people have downloaded
]project-open[ on Windows as opposed to the VM, or the tar ball.
In case you do not remember the numbers, please have a look at this URL:
Has anyone analyzed Naviserver performance and features vs. AOLserver
lately?
It appears to remain compatible with Windows.
The following forum post suggests Naviserver may be a contributing
factor to a significant overall performance increase:
On 2012-09-27, at 1:56 AM, Maurizio Martignano
maurizio.martign...@spazioit.com wrote:
So what are the feasible options?
I believe there are only two (well three) options:
1. we maintain the Windows code inside Aolserver (I favour this)
2. we compile Unix only code via the SUA SDK
3. we
How about making AolServer nothing more than a TEA-compliant extension? Maybe
we could create an ns_main command that created a thread that did all the
AolServer stuff (i.e., listen on sockets, create connection pools, etc. etc.)
and just run it in tclsh.
I never looked at TEA close enough
John Buckman wrote:
SUGGESTIONS FOR A FUTURE AOLSERVER
The state of the art is, I think, happening in the javascript world,
with things such as node.js. If the aolserver community were really
interested in getting new users, making it a top notch
embedded-javascript web server would be a
