Hi,

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

Reply via email to