That's a smart next step. Anybody want to tackle it and report back? I don't have the knowledge and am a bit biased :)
-Jim On Sep 26, 2012, at 10:48 AM, Scott Goodwin <sc...@scottg.net> wrote: > I would be surprised if we reached a yes or no consensus on removing Windows > support directly within the code since some number of people want to or are > required to use Windows for reasons similar to ones Rusty has provided. > Before debating such a yes or no decision, I would encourage exploring > options to enable AOLserver to run on Windows with the Windows-specific code > removed. I realize it's a non-starter for some to install Linux or other Unix > flavor as a guest OS on Windows within an all-Windows shop, but perhaps > there's a way to encapsulate AOLserver in a WINE-like container so that it > runs as an application on Windows without requiring a full VM. I'm by no > means an expert in this area, but it seems identifying various options that > exist or could exist and discussing and testing those should come first. If > there is a way to run under Windows without Windows code in the codebase, and > it meets Rusty's and others' Windows enclave requirements, then the decision > becomes obvious. Seems like this research would make a fine basis for someone > to do their thesis on, or submit as a Google SOC proposal. > > /s. > > > On Sep 26, 2012, at 11:10 AM, Rusty Brooks wrote: > >> Would windows still be supported via something like cygwin? If so then I >> guess I'm OK with this. I have not used AOLServer under windows much, but >> when I did, it was because I *had* to. Not having windows support would >> have sucked a lot. >> >> Rusty >> >> On Sep 26, 2012, at 10:07 AM, jgdavid...@mac.com wrote: >> >>> Every few years we talk about what's next for the strategic direction of >>> AOLserver which is great. In addition to the ideas below (which are cool), >>> I always bring up this question: Should we dump the Windows port in favor >>> of a clean Unix code base, configure, build, and install? >>> >>> I wrote most of that weird Windows code, including the goofy nsconfig >>> stuff. Some of it was curious, maybe even clever, but in the end it was a >>> distraction. It's impact on the config/build process in particular was >>> pretty significant. Today's Linux and OS/X environments are so much more >>> amenable to Aolserver, with threaded Tcl ready to go, gcc/make all pretty >>> stable. It wasn't like that in the early days! For me, a purge of the >>> Windows code and then an aggressive scan for anything still not 64-bit >>> compatible and cleanly build-able using standard configure/gcc/gmake tools >>> would be quite refreshing :) >>> >>> -Jim >>> >>> >>> >>> >>> On Sep 26, 2012, at 7:47 AM, Cesáreo García Rodicio <cesa...@cesareox.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> Firstly, thanks so much for your work. A lot of us are using aolserver >>>> everyday so this is welcome !! >>>> >>>> I'm not a hard developer but in my projects it's been hard students to >>>> install and use aolserver). And I think it's because documentation and >>>> installation: >>>> 1. TCL API and Config Files >>>> 2. "Packaged Installation" (batteries included) >>>> 3. Some Case Studies and Complete Examples with API (something simple). >>>> >>>> Only some ideas. Great Work! >>>> Cesáreo >>>> >>>> >>>> >>>> >>>> El 25/septiembre/12 05:29, Jeff Rogers escribió: >>>>> Hi all, >>>>> >>>>> There should be a 4.5.2 final release sometime soon, but what comes >>>>> next? I've been organizing my wishlist of what I'd like to see in >>>>> future AOLserver releases and I'm throwing it out there for anyone else >>>>> to add to or comment on. These are not in any particular order; some >>>>> are half-baked, some are straightforward, and some are little more than >>>>> speculation. I know development hands are a bit short these days, but >>>>> maybe people will find something that interests them to work on. >>>>> >>>>> Core features: >>>>> - support chunked postdata >>>>> - api for filter unregistration >>>>> - core async delivery >>>>> currently possible by transferring conn socket to tcl event loop. >>>>> Would be nice to make it work for everything, by default. >>>>> - re-queue api >>>>> extension of pre-queue filters and quewait api: allow a conn thread >>>>> to send a request back to quewait for network i/o. >>>>> - move encoding and compression to filters >>>>> - general-purpose worker-pool api >>>>> - external prebinding >>>>> allow an external program to bind ports and specify open file >>>>> descriptors on the command line; would allow privileged port binding >>>>> with no root privileges for actual server. Would also allow restarting >>>>> without closing listen socket. >>>>> - pre-start request service >>>>> have a micro server that responds to requests with "please wait" >>>>> while server is starting. Helpful for long start-up sequences. >>>>> >>>>> Core tcl: >>>>> - replace various c-coded file commands with tcl equivalents (e.g., >>>>> ns_mkdir, ns_unlink). Main benefit is clean handling of utf8 filenames. >>>>> - Support a 2-phase interp initialization. Phase 1 is defining procs / >>>>> loading packages, which is replicated in every new interp. Phase 2 is >>>>> initializing persistent data, preloading caches, setting up filters and >>>>> handlers, etc; things that are not replicated in every new interp. >>>>> >>>>> Nsdb: >>>>> - add variable binding to nsdb >>>>> - add lob handling to nsdb >>>>> - support runtime db pool configuration >>>>> >>>>> Protocols: >>>>> - SPDY >>>>> - websockets >>>>> I have a vague notion of how both of these could work. But it needs >>>>> somewhat more than that :) >>>>> >>>>> Documentation: >>>>> - Yes, please. >>>>> >>>>> Packaging: >>>>> - more config examples >>>>> - examples of various features >>>>> - configuration through web browser >>>>> - "batteries-included" distribution (binaries including perhaps sqlite, >>>>> zlib, openssl, a few simple web apps, maybe php, perl, ...?) >>>>> - single-file mountable packages, like tclkits >>>>> >>>>> Community: >>>>> - dogfood website >>>>> It'd be really nice if aolserver.com actually ran on aolserver. It's >>>>> hosted on sourceforge currently so probably not much chance of that as >>>>> it stands, but who knows. >>>>> >>>>> >>>>> Anything else to add? >>>>> >>>>> -J >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> will include endpoint security, mobile security and the latest in malware >>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> _______________________________________________ >>>>> aolserver-talk mailing list >>>>> aolserver-talk@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/aolserver-talk >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> aolserver-talk mailing list >>>> aolserver-talk@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/aolserver-talk >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> aolserver-talk mailing list >>> aolserver-talk@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/aolserver-talk >> >> >> ------------------------------------------------------------------------------ >> How fast is your code? >> 3 out of 4 devs don\\\'t know how their code performs in production. >> Find out how slow your code is with AppDynamics Lite. >> http://ad.doubleclick.net/clk;262219672;13503038;z? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> aolserver-talk mailing list >> aolserver-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/aolserver-talk > > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > aolserver-talk mailing list > aolserver-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aolserver-talk ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
