Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Fenton, Brian]

Great discussion going on here! Does anyone recall why Naviserver forked from 
AOLserver? Was it for technical reasons, or "issues" in the community? It still 
seems a waste of resources in an already small community.

Brian


From: Gustaf Neumann [neum...@wu.ac.at]
Sent: 28 September 2012 10:35
To: aolserver-talk@lists.sourceforge.net
Subject: Re: [AOLSERVER] Roadmap - 4.6 and beyond

As a contributor to aolserver and naviserver i want to add a
few comments
- we are running between 30 and 50 servers for various
projects,
   i would say that 70% are naviserver right now.
- the reason we switched from aolserver to naviserver was that
   with our load-pattern (using OpenACS) we experienced some
problems:
   * up to about 1000 concurrent users aolserver was
perfectly fine
   * above this, we saw crashes, running out of resources
(connection threads),
 memory growth, etc., thread lockups, micro-lockups for
a few seconds.
 Some of these lead to contributions to aolserver i did
in the past
   * to pinpoint the problem we moved to Zoran's setup
 (tcl version, naviserver), that went though heaving
testing on his side
 and was rock-stable
   * some of our problems disappeared/changed, some not
(burst creation
 of theads,...). We have quite different load patterns
than zoran.
   * we found sources for our problems at various places
(server, tcl, ...
 machine architecture) depending as well on e.g. tcl
versions etc.

By now, most of the problems are gone, we are using
NaviServer in
production since more than two years. A summary is on the
link referenced below. Even more recently, we exchanged the
hardware to a more mainstream one (this improved the
performance by a factor of 3-4!). The fact that e.g. the
resource
consumption went down, helped a lot to run on a much cheaper
machine
(memory consumption, max number of connection threads went
from 80 to 30, etc.).

Btw., in this process of moving from POWER to Intel apparently
the biggest  source of our crashes went away. The way Tcl
handles
thread-local storage (Tcl 8.5) seems to cause under heavy load
race conditions, which lead to crashes in otherwise stable
code-pieces (e.g. regexp). I rewrote some of the usages of the
tls infrastructure in tcl to use GCC's non-standard tls
handling via
  "__thread", then the problem went from regexp to other
places using tls). The problem was most likely dirty reads
in tcl +
mutex handling + POWER + gcc (from rhel). Tcl 8.6 is
supposed to be better in this regard.

For the changes in naviserver, see [1]. With the recent
versions of
naviserver/tcl 8.5/libthread the server runs in a stable
memory size, without
the need for daily reboots (although a reboot has some nice
"self-healing"
properties for nsvs, etc.). See [2] for a statistics from a
machine with
two naviservers with different configuration running (alice,
nm).
Among other things one can see the stable rss and vsizes of
the servers
over the last few months.

Aolserver is in terms of memory leaks not so bad either. One
can see
on [3] the statistics from openacs.org and
translate.openacs.org which
is runing aolserver 4.5.1. One can see, where we fixed an
application
leak in May [4].

[1]
https://bitbucket.org/naviserver/naviserver/src/5df3b1cb9ea6/NEWS
[2]
http://alice.wu.ac.at/munin/wu.ac.at/alice.wu.ac.at/index.html#naviserver
[3]
http://openacs.org/munin/localdomain/localhost.localdomain/index.html#naviserver
[4]
http://openacs.org/munin/localdomain/localhost.localdomain/naviserver_translate_memsize.html

Concerning the comments below
- the documentation of naviserver is at least par with
aolserver
   (the man pages are quite good).
- for me, the the biggest pain is the aolserver->naviserver
   config file conversion, but the actual documented
   config files on bitbucket contain now all values read
from the
   server with the default values.
- porting all the changes from naviserver into aolserver is
   much more work than the other way round. i have no
   problem with the coexistence of naviserver and aolserver,
   providing urgent changes to both servers (as i have done
in the past).
- both aolserver and naviserver are stable and mature (having
   advantages and disadvantages), the people running large sites
   are rather conservative. Having alternatives is rather a
selling
   argument. If e.g. aolserver is dropping windows support,
   naviserver can continue it (or vice versa).

-gustaf neumann


On 27.09.12 23:25, John Buckman from BookMooch wrote:
> Naviserver has added a lot of interesting features, and appears to be fairly 
> mature.
>
> I would have probably switched to Naviserver two years ago if they had 
> documented some of their changes.  The quantity of the contributions, and the 
> interesting nature of many of them, make me feel that Naviserver is far from 
> "end of life".
>
> When I switched (temporarily) 

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[aT]

Feature request .

- possibility to reload configuration, without restart.

---
from phone ..
On Sep 28, 2012 1:36 PM, "Gustaf Neumann"  wrote:

> As a contributor to aolserver and naviserver i want to add a
> few comments
> - we are running between 30 and 50 servers for various
> projects,
>i would say that 70% are naviserver right now.
> - the reason we switched from aolserver to naviserver was that
>with our load-pattern (using OpenACS) we experienced some
> problems:
>* up to about 1000 concurrent users aolserver was
> perfectly fine
>* above this, we saw crashes, running out of resources
> (connection threads),
>  memory growth, etc., thread lockups, micro-lockups for
> a few seconds.
>  Some of these lead to contributions to aolserver i did
> in the past
>* to pinpoint the problem we moved to Zoran's setup
>  (tcl version, naviserver), that went though heaving
> testing on his side
>  and was rock-stable
>* some of our problems disappeared/changed, some not
> (burst creation
>  of theads,...). We have quite different load patterns
> than zoran.
>* we found sources for our problems at various places
> (server, tcl, ...
>  machine architecture) depending as well on e.g. tcl
> versions etc.
>
> By now, most of the problems are gone, we are using
> NaviServer in
> production since more than two years. A summary is on the
> link referenced below. Even more recently, we exchanged the
> hardware to a more mainstream one (this improved the
> performance by a factor of 3-4!). The fact that e.g. the
> resource
> consumption went down, helped a lot to run on a much cheaper
> machine
> (memory consumption, max number of connection threads went
> from 80 to 30, etc.).
>
> Btw., in this process of moving from POWER to Intel apparently
> the biggest  source of our crashes went away. The way Tcl
> handles
> thread-local storage (Tcl 8.5) seems to cause under heavy load
> race conditions, which lead to crashes in otherwise stable
> code-pieces (e.g. regexp). I rewrote some of the usages of the
> tls infrastructure in tcl to use GCC's non-standard tls
> handling via
>   "__thread", then the problem went from regexp to other
> places using tls). The problem was most likely dirty reads
> in tcl +
> mutex handling + POWER + gcc (from rhel). Tcl 8.6 is
> supposed to be better in this regard.
>
> For the changes in naviserver, see [1]. With the recent
> versions of
> naviserver/tcl 8.5/libthread the server runs in a stable
> memory size, without
> the need for daily reboots (although a reboot has some nice
> "self-healing"
> properties for nsvs, etc.). See [2] for a statistics from a
> machine with
> two naviservers with different configuration running (alice,
> nm).
> Among other things one can see the stable rss and vsizes of
> the servers
> over the last few months.
>
> Aolserver is in terms of memory leaks not so bad either. One
> can see
> on [3] the statistics from openacs.org and
> translate.openacs.org which
> is runing aolserver 4.5.1. One can see, where we fixed an
> application
> leak in May [4].
>
> [1]
> https://bitbucket.org/naviserver/naviserver/src/5df3b1cb9ea6/NEWS
> [2]
> http://alice.wu.ac.at/munin/wu.ac.at/alice.wu.ac.at/index.html#naviserver
> [3]
>
> http://openacs.org/munin/localdomain/localhost.localdomain/index.html#naviserver
> [4]
>
> http://openacs.org/munin/localdomain/localhost.localdomain/naviserver_translate_memsize.html
>
> Concerning the comments below
> - the documentation of naviserver is at least par with
> aolserver
>(the man pages are quite good).
> - for me, the the biggest pain is the aolserver->naviserver
>config file conversion, but the actual documented
>config files on bitbucket contain now all values read
> from the
>server with the default values.
> - porting all the changes from naviserver into aolserver is
>much more work than the other way round. i have no
>problem with the coexistence of naviserver and aolserver,
>providing urgent changes to both servers (as i have done
> in the past).
> - both aolserver and naviserver are stable and mature (having
>advantages and disadvantages), the people running large sites
>are rather conservative. Having alternatives is rather a
> selling
>argument. If e.g. aolserver is dropping windows support,
>naviserver can continue it (or vice versa).
>
> -gustaf neumann
>
>
> On 27.09.12 23:25, John Buckman from BookMooch wrote:
> > Naviserver has added a lot of interesting features, and appears to be
> fairly mature.
> >
> > I would have probably switched to Naviserver two years ago if they had
> documented some of their changes.  The quantity of the contributions, and
> the interesting nature of many of them, make me feel that Naviserver is far
> from "end of life".
> >
> > When I switched (temporarily) to naviserver I found enough things that
> didn't work like aolserver, yet were totally undocumented, that the
> experience was very fru

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Gustaf Neumann]

As a contributor to aolserver and naviserver i want to add a 
few comments
- we are running between 30 and 50 servers for various 
projects,
   i would say that 70% are naviserver right now.
- the reason we switched from aolserver to naviserver was that
   with our load-pattern (using OpenACS) we experienced some 
problems:
   * up to about 1000 concurrent users aolserver was 
perfectly fine
   * above this, we saw crashes, running out of resources 
(connection threads),
 memory growth, etc., thread lockups, micro-lockups for 
a few seconds.
 Some of these lead to contributions to aolserver i did 
in the past
   * to pinpoint the problem we moved to Zoran's setup
 (tcl version, naviserver), that went though heaving 
testing on his side
 and was rock-stable
   * some of our problems disappeared/changed, some not 
(burst creation
 of theads,...). We have quite different load patterns 
than zoran.
   * we found sources for our problems at various places 
(server, tcl, ...
 machine architecture) depending as well on e.g. tcl 
versions etc.

By now, most of the problems are gone, we are using 
NaviServer in
production since more than two years. A summary is on the
link referenced below. Even more recently, we exchanged the
hardware to a more mainstream one (this improved the
performance by a factor of 3-4!). The fact that e.g. the 
resource
consumption went down, helped a lot to run on a much cheaper 
machine
(memory consumption, max number of connection threads went
from 80 to 30, etc.).

Btw., in this process of moving from POWER to Intel apparently
the biggest  source of our crashes went away. The way Tcl 
handles
thread-local storage (Tcl 8.5) seems to cause under heavy load
race conditions, which lead to crashes in otherwise stable
code-pieces (e.g. regexp). I rewrote some of the usages of the
tls infrastructure in tcl to use GCC's non-standard tls 
handling via
  "__thread", then the problem went from regexp to other
places using tls). The problem was most likely dirty reads 
in tcl +
mutex handling + POWER + gcc (from rhel). Tcl 8.6 is
supposed to be better in this regard.

For the changes in naviserver, see [1]. With the recent 
versions of
naviserver/tcl 8.5/libthread the server runs in a stable 
memory size, without
the need for daily reboots (although a reboot has some nice 
"self-healing"
properties for nsvs, etc.). See [2] for a statistics from a 
machine with
two naviservers with different configuration running (alice, 
nm).
Among other things one can see the stable rss and vsizes of 
the servers
over the last few months.

Aolserver is in terms of memory leaks not so bad either. One 
can see
on [3] the statistics from openacs.org and 
translate.openacs.org which
is runing aolserver 4.5.1. One can see, where we fixed an 
application
leak in May [4].

[1] 
https://bitbucket.org/naviserver/naviserver/src/5df3b1cb9ea6/NEWS
[2] 
http://alice.wu.ac.at/munin/wu.ac.at/alice.wu.ac.at/index.html#naviserver
[3] 
http://openacs.org/munin/localdomain/localhost.localdomain/index.html#naviserver
[4] 
http://openacs.org/munin/localdomain/localhost.localdomain/naviserver_translate_memsize.html

Concerning the comments below
- the documentation of naviserver is at least par with 
aolserver
   (the man pages are quite good).
- for me, the the biggest pain is the aolserver->naviserver
   config file conversion, but the actual documented
   config files on bitbucket contain now all values read 
from the
   server with the default values.
- porting all the changes from naviserver into aolserver is
   much more work than the other way round. i have no
   problem with the coexistence of naviserver and aolserver,
   providing urgent changes to both servers (as i have done 
in the past).
- both aolserver and naviserver are stable and mature (having
   advantages and disadvantages), the people running large sites
   are rather conservative. Having alternatives is rather a 
selling
   argument. If e.g. aolserver is dropping windows support,
   naviserver can continue it (or vice versa).

-gustaf neumann


On 27.09.12 23:25, John Buckman from BookMooch wrote:
> Naviserver has added a lot of interesting features, and appears to be fairly 
> mature.
>
> I would have probably switched to Naviserver two years ago if they had 
> documented some of their changes.  The quantity of the contributions, and the 
> interesting nature of many of them, make me feel that Naviserver is far from 
> "end of life".
>
> When I switched (temporarily) to naviserver I found enough things that didn't 
> work like aolserver, yet were totally undocumented, that the experience was 
> very frustrating and I went back to aolserver.  I was spending too much time 
> reading C source code to figure things out.
>
> So... my personal vote for an aolserver v5 would be merging in lots of the 
> naviserver code changes into aolserver.  There's a lot of bang-for-our-buck 
> there.  Or, simply running with naviserver, if we (the aolserver c

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Jeff Rogers]

jgdavid...@mac.com wrote:
>
> and those NS_IMPORT/NS_EXPORT
> declarations.

Those are less of a windows-only thing now.  Some recent version of gcc 
introduced visibility attributes which are supposed to be super good for 
improving link times or something like that, so unix with a new-enough 
gcc and the default compiler flags pulled in from tcl now needs

#  define NS_EXPORT __attribute__ ((visibility ("default")))

to allow linking with shared libraries.  Having all those NS_EXPORTs 
already in place greatly simplified fixing this build problem.

-J

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[jgdavidson]

Howdy,

The point about libraries only available on Windows is a compelling reason for 
some support, given it mostly works today.


Honestly, AolServer isn't so bad at supporting Windows.  I wrote most of the 
cross-platform code and was able to smash down quite a bit of the differences.  
The approach was to assume the programmer was versed in both Unix and Windows 
programming and just look for the minimally-invasive intersection between the 
two, using #idef's throughout as needed.  This differs from Tcl where they do a 
great job isolating the platform code in the win/ source directory.

You see the result, for example, with the SOCKET "type".  It's a Windows thing, 
sprinkled throughout AolServer core, because SOCKET's aren't the same as file 
descriptors on Windows.  So, as a Unix programmer, you have to stop and think 
"what's this SOCKET thing?" which is either a curiosity or a minor speed bump.  
Other weird Window'ism lurking are in process forking, log file moving, the 
"Server Control Manager", and those NS_IMPORT/NS_EXPORT declarations.

The AolServer thread library is an exception.  It stands alone and does a good 
job of providing a pthread-like interface for Windows and some value add (e.g., 
mutex lock contention counters, object names, a few other things).


I think the answer to "what's the cross-platform burden..." is:

1.  When you are writing core code on Unix, you have to still be thinking about 
Windows -- those SOCKET things, NS_EXPORT's and such, is there a drive letter 
in the path?  Is there a \r before the \n in the line?  -- those sorts of 
things.  This can slow you down a little.

2.  When you finally go to build on Windows, you have trouble setting up a 
build environment and resolving dependencies (e.g., OpenSSL, Tcl, etc.).  This 
can be a real drag.  This was particularly stressful for me because it always 
felt like a low-value time sink, often frustrating.


So, I think the opportunity for re-factoring is not in the code, it's in the 
build environment.  If someone can figure that out, it could be ok.  I tried 
with the goofy nsconfig.tcl script and failed.   


-Jim





On Sep 27, 2012, at 7:25 AM, Andrew Piskorski  wrote:

> On Wed, Sep 26, 2012 at 09:07:07AM -0600, jgdavid...@mac.com wrote:
> 
>> Should we dump the Windows port in favor of a clean Unix code base,
>> configure, build, and install?
> 
> Cross-platform portability is very Nice to Have, and I've actually
> used it.  Fortunately I've never had to deal with or even look at the
> Unix vs. Windows compatibility layer, so I can't speak on its
> maintenance burden.  It just worked.  That was really nice when
> (unexpectedly) porting my code from Solaris to Windows.
> 
> The AOLserver Windows build process back then indeed seemed pretty
> bad; far too much unscriptable Microsoft project file crap.  But I
> thought someone cleaned that up later.
> 
> On Wed, Sep 26, 2012 at 09:24:41AM -0600, jgdavid...@mac.com wrote:
> 
>> For folks using Windows, I always follow up with the question: With
>> VMware, Parallels, etc. today, even if you're bound to Windows
>> hardware, can you just virtualize away the difference?
> 
> Absolutely not.  In my case, it's because I use AOLserver as a custom
> app server, which needs to build against proprietary libraries that
> are ONLY available on Windows.  If what you need is a native Windows
> library, running Linux in a virtualized container is of no help
> whatsoever, you might as well be running on a remote Linux box.
> (Cygwin I'm not sure about.  Can Cygwin applications build with native
> Windows libraries?)
> 
> In my case, actually what happened is the proprietary vendor library
> discontinued Solaris support, leaving only Windows, so I ported to
> Windows.  I'm still running it on Windows today.  Now, if I was
> writing that same app today I might do things somewhat differently.
> But it was Really Nice that the custom AOLserver app I'd originally
> written on Solaris mostly Just Worked when I ported it to Windows.
> 
> My own AOLserver on Windows use case is likely very atypical, but I
> think it's still a useful minor example of how cross-platform
> portability can be unexpectedly helpful, even when you originally
> didn't think you'd need or want it.
> 
> Is cross-platform support in AOLserver worth the maintenance burden?
> Not having worked on that code, I can't say.  But I can say that the
> cross-platform code does have real value, and was probably a lot of
> work to get right way back when, so I'd caution against throwing it
> out without a very clear case that doing so is worth more than the
> loss, and that there isn't some better way to achieve the same gains.
> 
> My (completely unfounded in any hard evidence) gut-level suspicion is
> that 80% of the simplicity gains to be had from completely discarding
> Windows support are likely achievable by instead re-factoring (somehow
> or other) whatever parts are actually giving maintainers the most
> trouble.
> 

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[John Buckman from BookMooch]

Naviserver has added a lot of interesting features, and appears to be fairly 
mature.

I would have probably switched to Naviserver two years ago if they had 
documented some of their changes.  The quantity of the contributions, and the 
interesting nature of many of them, make me feel that Naviserver is far from 
"end of life".

When I switched (temporarily) to naviserver I found enough things that didn't 
work like aolserver, yet were totally undocumented, that the experience was 
very frustrating and I went back to aolserver.  I was spending too much time 
reading C source code to figure things out.

So... my personal vote for an aolserver v5 would be merging in lots of the 
naviserver code changes into aolserver.  There's a lot of bang-for-our-buck 
there.  Or, simply running with naviserver, if we (the aolserver community) can 
get it to a point where we're comfortable with it.

-john



On Sep 27, 2012, at 8:19 AM, Torben Brosten wrote:

> 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:
> 
> http://openacs.org/forums/message-view?message_id=3957131



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Torben Brosten]

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:

http://openacs.org/forums/message-view?message_id=3957131

Maybe AOLserver 5 should start as a fork of Naviserver?  ;-)


On 09/27/2012 06:25 AM, Andrew Piskorski wrote:
> On Wed, Sep 26, 2012 at 09:07:07AM -0600, jgdavid...@mac.com wrote:
>
>> Should we dump the Windows port in favor of a clean Unix code base,
>> configure, build, and install?
>
> Cross-platform portability is very Nice to Have, and I've actually
> used it.  Fortunately I've never had to deal with or even look at the
> Unix vs. Windows compatibility layer, so I can't speak on its
> maintenance burden.  It just worked.  That was really nice when
> (unexpectedly) porting my code from Solaris to Windows.
>
> The AOLserver Windows build process back then indeed seemed pretty
> bad; far too much unscriptable Microsoft project file crap.  But I
> thought someone cleaned that up later.
>
> On Wed, Sep 26, 2012 at 09:24:41AM -0600, jgdavid...@mac.com wrote:
>
>> For folks using Windows, I always follow up with the question: With
>> VMware, Parallels, etc. today, even if you're bound to Windows
>> hardware, can you just virtualize away the difference?
>
> Absolutely not.  In my case, it's because I use AOLserver as a custom
> app server, which needs to build against proprietary libraries that
> are ONLY available on Windows.  If what you need is a native Windows
> library, running Linux in a virtualized container is of no help
> whatsoever, you might as well be running on a remote Linux box.
> (Cygwin I'm not sure about.  Can Cygwin applications build with native
> Windows libraries?)
>
> In my case, actually what happened is the proprietary vendor library
> discontinued Solaris support, leaving only Windows, so I ported to
> Windows.  I'm still running it on Windows today.  Now, if I was
> writing that same app today I might do things somewhat differently.
> But it was Really Nice that the custom AOLserver app I'd originally
> written on Solaris mostly Just Worked when I ported it to Windows.
>
> My own AOLserver on Windows use case is likely very atypical, but I
> think it's still a useful minor example of how cross-platform
> portability can be unexpectedly helpful, even when you originally
> didn't think you'd need or want it.
>
> Is cross-platform support in AOLserver worth the maintenance burden?
> Not having worked on that code, I can't say.  But I can say that the
> cross-platform code does have real value, and was probably a lot of
> work to get right way back when, so I'd caution against throwing it
> out without a very clear case that doing so is worth more than the
> loss, and that there isn't some better way to achieve the same gains.
>
> My (completely unfounded in any hard evidence) gut-level suspicion is
> that 80% of the simplicity gains to be had from completely discarding
> Windows support are likely achievable by instead re-factoring (somehow
> or other) whatever parts are actually giving maintainers the most
> trouble.
>


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Andrew Piskorski]

On Wed, Sep 26, 2012 at 09:07:07AM -0600, jgdavid...@mac.com wrote:

> Should we dump the Windows port in favor of a clean Unix code base,
> configure, build, and install?

Cross-platform portability is very Nice to Have, and I've actually
used it.  Fortunately I've never had to deal with or even look at the
Unix vs. Windows compatibility layer, so I can't speak on its
maintenance burden.  It just worked.  That was really nice when
(unexpectedly) porting my code from Solaris to Windows.

The AOLserver Windows build process back then indeed seemed pretty
bad; far too much unscriptable Microsoft project file crap.  But I
thought someone cleaned that up later.

On Wed, Sep 26, 2012 at 09:24:41AM -0600, jgdavid...@mac.com wrote:

> For folks using Windows, I always follow up with the question: With
> VMware, Parallels, etc. today, even if you're bound to Windows
> hardware, can you just virtualize away the difference?

Absolutely not.  In my case, it's because I use AOLserver as a custom
app server, which needs to build against proprietary libraries that
are ONLY available on Windows.  If what you need is a native Windows
library, running Linux in a virtualized container is of no help
whatsoever, you might as well be running on a remote Linux box.
(Cygwin I'm not sure about.  Can Cygwin applications build with native
Windows libraries?)

In my case, actually what happened is the proprietary vendor library
discontinued Solaris support, leaving only Windows, so I ported to
Windows.  I'm still running it on Windows today.  Now, if I was
writing that same app today I might do things somewhat differently.
But it was Really Nice that the custom AOLserver app I'd originally
written on Solaris mostly Just Worked when I ported it to Windows.

My own AOLserver on Windows use case is likely very atypical, but I
think it's still a useful minor example of how cross-platform
portability can be unexpectedly helpful, even when you originally
didn't think you'd need or want it.

Is cross-platform support in AOLserver worth the maintenance burden?
Not having worked on that code, I can't say.  But I can say that the
cross-platform code does have real value, and was probably a lot of
work to get right way back when, so I'd caution against throwing it
out without a very clear case that doing so is worth more than the
loss, and that there isn't some better way to achieve the same gains.

My (completely unfounded in any hard evidence) gut-level suspicion is
that 80% of the simplicity gains to be had from completely discarding
Windows support are likely achievable by instead re-factoring (somehow
or other) whatever parts are actually giving maintainers the most
trouble.

-- 
Andrew Piskorski 

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Brett Schwarz]

First, Jeff thanks for initiating this thread...all the ideas seem good. One 
note below.


- Original Message -
> From: Jeff Rogers 
> To: Ayan George 
> Cc: aolserver-talk@lists.sourceforge.net
> Sent: Wednesday, September 26, 2012 9:28 AM
> Subject: Re: [AOLSERVER] Roadmap - 4.6 and beyond
> 
> Ayan George wrote:
> 
>>  Can we:
>> 
>>  * Allow c99 language features.
> 
> This might impact platform support, or that might be a non-issue.  Any 
> specifics on what you're looking for?
> 
>>  * Fully support HTTP 1.1
> 
> I thought about this but without digging in I couldn't recall which 
> pieces are missing (other than chunked encoding).
> 
>>  * Support configuring multiple servers using namespaces in the
>>  configuration file?
> 
> Sounds interesting, can you be more specific?  Maybe create a sample 
> config file showing what you'd like to work.


I had proposed something similar for naviserver a while back. To me the config 
file just screamed namespace, but maybe that's just me. See here for a simply 
example of what I was thinking a few years back:

http://permalink.gmane.org/gmane.comp.web.naviserver.devel/152 


Cheers,
    --brett

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Daniël Mantione]

Op Wed, 26 Sep 2012, schreef Jay Rohr:


I'm not well versed in pv6, but one concern I have about your patch is
that it looks like it changes everything to support only ipv6, with ipv4
in compatibility "mapped" mode.  Could that break compatibility for some
older systems?  Do we care?


YES! :-)


I care about older systems too, people often claim I even care too much 
about older systems.


But everything within reason. I'm not sure if there is a real problem. Can 
you point out which older systems you believe are affected by this patch?


Daniël--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Daniël Mantione]

Op Wed, 26 Sep 2012, schreef Jeff Rogers:

I'm not well versed in pv6, but one concern I have about your patch is that 
it looks like it changes everything to support only ipv6, with ipv4 in 
compatibility "mapped" mode.  Could that break compatibility for some older 
systems?  Do we care?


The patch requires that the libc supports the ipv6 API's, but not that the 
operating system has ipv6 support. For example, you can compile you Linux 
kernel without ipv6 support and it will still happily do ipv4 only.


So, to make it clear, you have 100% support for IPV4 only systems with 
this patch applied.


I think you have to go quite a way back into the past to find a libc 
without ipv6 support, ipv6 was added to Linux in the 1990's. I not 
worrying about FreeBSD's ipv6 support either.


There might be some old servers running a commercial Unix with a libc with 
ipv6 support. I am tempted to say I'd first like to see if they actually 
exists, rather than taking steps beforehand...


...because: Should we need to support both API's, the the best way is to 
put all modification inside #ifdef. That is not nice from a code 
maintenance point of view.


Daniël--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Ayan George]

On 09/26/2012 12:28 PM, Jeff Rogers wrote:
> Ayan George wrote:
>
>> Can we:
>>
>> * Allow c99 language features.
>
> This might impact platform support, or that might be a non-issue.  Any
> specifics on what you're looking for?

IIRC, newer versions of GCC default to gnu99 as the language standard 
which allows for stuff like inline variable declaration and declarations 
in for loops that can make for clearer and more concise code.

But also I want this in part because sticking to an older standard gives 
AOLserver a 'legacy' feel.  As I understand it, we're quite a small 
project now which gives us more freedom to abandon some of the cruft 
(old standards, unfavorable platforms and operating systems, outdated 
coding idioms, etc.)

I've tested this myself and tcl and aolserver build and run just fine 
with -std=c99 or -std=gnu99 flags.

>
>> * Fully support HTTP 1.1
>
> I thought about this but without digging in I couldn't recall which
> pieces are missing (other than chunked encoding).
>

Okay -- I'm not very familiar with what HTTP 1.1 bits are missing. 
Perhaps assessing what is necessary to make it 1.1 compliant should be 
part of the effort.

>> * Support configuring multiple servers using namespaces in the
>> configuration file?
>
> Sounds interesting, can you be more specific?  Maybe create a sample
> config file showing what you'd like to work.
>

Sorry -- this wasn't a very well thought out item.  I've always wondered 
why the configuration file used Ns_Set()s and I thought that we could 
use regular TCL variables with namespaces to confine the scope of 
configuration items to a server instance.  This seems cleaner and might 
make more sense for people who know TCL.

>> As far as development goes, can we move to git as the main way to
>> maintain code and adopt more modern ways of submitting patches?
>
> This is a tough one.  Dossy created a github project a year or two ago,
> but it hasn't seen a lot of use.  The development center is currently on
> sourceforge, and migrating a project is a big effort not to be taken
> lightly.  Some of us are also old farts and not very skilled with git
> and/or turned off by the intense debates over its merits.
>

I think much of the work is already done.  It is just a matter of 
pushing changes to github.  Github has some really nice features like 
making tarballs out of tags.  I highly recommend that we consider moving 
development to github.

> My current feeling on this is that there are not enough active
> developers right now to make cvs really problematic.  An influx of
> interest and contributors would change this, but I'd prefer to defer the
> big job of repository changing until it looks more necessary.
>

Okay -- fair enough.  I've just found using git and the common git 
workflow to be really nice compared with CVS or SVN.  I know this can 
become a huge debate.

I think which SCM tools are used can be a factor when developers pick 
projects to contribute to and I think CVS will hinder us in this regard.

-ayan

--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Scott Goodwin]

First step would be to identify various possibilities for running AOLserver on 
Windows within some kind of minimal VM that's not a full VM (or other option 
that will meet requirements in some way). I mentioned WINE as an example of the 
type of capability that I think would be ideal; WINE allows Windows code to run 
on Linux without a VM by intercepting the calls to the OS and servicing them 
with code that makes the app think it's on Windows. We would be looking for the 
reverse -- a container that runs on Windows, intercepts calls to the OS from 
the encapsulated app, and services them so the app thinks it's on a Unix type 
system. If memory serves me well, Cygwin is a compilation environment that 
provides Unix-style APIs on Windows so Unixy code compile on Windows and runs 
on Windows without extensive mods to the Unixy style code. That or another 
compilation environment sounds promising, but I'm hoping there is some kind of 
runtime container that can run a Linux or other Unix executable on without 
requiring that the encapsulated app (AOLserver) be (re)compiled on the Windows 
OS directly, kind of like how starkits can package up Tcl apps with the interp 
and all the necessary runtime stuff in one file.

/s.


On Sep 26, 2012, at 12:53 PM, jgdavid...@mac.com wrote:

> 
> 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  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  
 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
>> futur

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Ayan George]

On 09/26/2012 12:51 PM, jgdavid...@mac.com wrote:
>
> Simple makefiles alone sure makes sense to explore first -- things are far 
> more standardized, that's true.
>

I completely agree.  I've done this personally as well and I think it is 
a good idea.  I'd be interested in tackling this.

-ayan



--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[jgdavidson]

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  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  
>>> 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 fil

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[jgdavidson]

Simple makefiles alone sure makes sense to explore first -- things are far more 
standardized, that's true.

Back in 1995 I had to support 4 thread libraries: Pthreads, "draft" Pthreads, 
Solaris, SGI native, and Win32.  I guess that's 5.  The most interesting one 
was SGI, had a process "group" where threads where created via "sproc", a big 
mmap'ed "arena" for lock synchronization, and Unix signals for sending wakeup 
in underlying custom-coded condition variables.  The SGI debugger worked well 
too.  All interesting and utterly unimportant today :)

-Jim


On Sep 26, 2012, at 10:32 AM, Jeff Rogers  wrote:

> jgdavid...@mac.com wrote:
>> 
>> 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 :)
> 
> Even more radically, could we drop autoconf entirely in favor of 2 or 3 clean 
> makefiles?  The general feeling I've gotten is that modern unix platforms are 
> far less different now than several years ago.
> 
> -J


--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Scott Goodwin]

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  
>> 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, p

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Jeff Rogers]

jgdavid...@mac.com wrote:
>
> 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 :)

Even more radically, could we drop autoconf entirely in favor of 2 or 3 
clean makefiles?  The general feeling I've gotten is that modern unix 
platforms are far less different now than several years ago.

-J

--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Jeff Rogers]

Ayan George wrote:

> Can we:
>
> * Allow c99 language features.

This might impact platform support, or that might be a non-issue.  Any 
specifics on what you're looking for?

> * Fully support HTTP 1.1

I thought about this but without digging in I couldn't recall which 
pieces are missing (other than chunked encoding).

> * Support configuring multiple servers using namespaces in the
> configuration file?

Sounds interesting, can you be more specific?  Maybe create a sample 
config file showing what you'd like to work.

> As far as development goes, can we move to git as the main way to
> maintain code and adopt more modern ways of submitting patches?

This is a tough one.  Dossy created a github project a year or two ago, 
but it hasn't seen a lot of use.  The development center is currently on 
sourceforge, and migrating a project is a big effort not to be taken 
lightly.  Some of us are also old farts and not very skilled with git 
and/or turned off by the intense debates over its merits.

My current feeling on this is that there are not enough active 
developers right now to make cvs really problematic.  An influx of 
interest and contributors would change this, but I'd prefer to defer the 
big job of repository changing until it looks more necessary.

-J


--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Scott Goodwin]

Yes.

/s.

On Sep 26, 2012, at 11:07 AM, jgdavid...@mac.com wrote:

> 
> 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  
> 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-tal

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Jay Rohr]

On Sep 26, 2012, at 12:03 PM, Jeff Rogers  wrote:

> Daniël Mantione wrote:
> 
>> IPV6, please, please, please!
>> 
>> Seriously, lack of IPV6 support is the perfect excuse to phase out an
>> AOLServer installation.
>> 
>> Depending on how long it will take to produce 4.6, maybe even consider a
>> 4.5 series release with ipv6, I have noticed any instabilities of my
>> patch at least.
>> 
>> My patch: http://www.freepascal.org/~daniel/aolserver-ipv6support.diff
> 
> Definitely a good idea; I'll add it to the list (which I'll put up on 
> the wiki sometime soon).
> 
> I'm not well versed in pv6, but one concern I have about your patch is 
> that it looks like it changes everything to support only ipv6, with ipv4 
> in compatibility "mapped" mode.  Could that break compatibility for some 
> older systems?  Do we care?

YES! :-)

> 
> -J
> 
> 
> --
> 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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Jeff Rogers]

Wolfgang Winkler wrote:
> Hi!
>
> Concerning websockets: I've written a tcl only solution for AOLserver
> which works very well for pushing data to thousands of clients. The only
> problem is the receiving end, as I've to poll all open sockets in
> [ns_chan -shared] because I don't get the events of the single sockets.
> If this worked, AOLserver would be the perfect tool for handling websockets.

Can you share your code?  It would certainly make a good starting point 
for anyone else looking to do this.

-J


--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Jeff Rogers]

Sep Ng wrote:
> I say this half in jest but if tuning Aolserver can become less like
> black magic, that would be a huge plus!

Yeah, this is what I was thinking about with some better docs and a 
configuration ui, maybe some auto-configuration scripts that look at 
system memory size and the like.

-J

--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Jeff Rogers]

Daniël Mantione wrote:

> IPV6, please, please, please!
>
> Seriously, lack of IPV6 support is the perfect excuse to phase out an
> AOLServer installation.
>
> Depending on how long it will take to produce 4.6, maybe even consider a
> 4.5 series release with ipv6, I have noticed any instabilities of my
> patch at least.
>
> My patch: http://www.freepascal.org/~daniel/aolserver-ipv6support.diff

Definitely a good idea; I'll add it to the list (which I'll put up on 
the wiki sometime soon).

I'm not well versed in pv6, but one concern I have about your patch is 
that it looks like it changes everything to support only ipv6, with ipv4 
in compatibility "mapped" mode.  Could that break compatibility for some 
older systems?  Do we care?

-J


--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Rusty Brooks]

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  
> 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. D

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Rusty Brooks]

I would say no, not really.  Ask yourself why people want to use windows and 
the answer usually is, that's where all of their experience, support, 
infrastructure, etc is.  You're going to ask them to also maintain a VM and 
another OS?  I mean if running aolserver on linux was an option for them they'd 
probably just install linux on a machine and do it.

The times I've had to use windows was usually doing a project for a client 
who's entire IT department and (paid) tech support systems were windows only.  
If I'd installed a linux VM on their systems I doubt they'd consider that a win.

I don't really actively develop on AOLServer any more so don't take my word for 
it, but all I can say is that in the past windows versions of aolserver have 
saved my bacon - the alternative would usually have been re-developing huge 
segments of code for something that would run on windows.

Rusty


On Sep 26, 2012, at 10:24 AM, jgdavid...@mac.com wrote:

> 
> 
> For folks using Windows, I always follow up with the question:  With VMware, 
> Parallels, etc. today, even if you're bound to Windows hardware, can you just 
> virtualize away the difference?  
> 
> Otherwise, I can't say if Cygwin would work -- I haven't looked at Windows 
> development, native or via emulator/configure thingers in years.
> 
> -Jim
> 
> 
> 
> 
> On Sep 26, 2012, at 9: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  
>>> 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 equivale

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[jgdavidson]

For folks using Windows, I always follow up with the question:  With VMware, 
Parallels, etc. today, even if you're bound to Windows hardware, can you just 
virtualize away the difference?  

Otherwise, I can't say if Cygwin would work -- I haven't looked at Windows 
development, native or via emulator/configure thingers in years.

-Jim




On Sep 26, 2012, at 9: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  
>> 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:

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Ayan George]

On 09/26/2012 11: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 :)
>



Yes!  I think so.  I wanted to add that to my list but I was afraid it 
was too controversial.

But I think dumping windows support would be a great thing.  I worked on 
this in a local branch was very happy with the results.

-ayan





--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[jgdavidson]

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  
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
>> 
> 
> --
> Liv

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Cesáreo García Rodicio]

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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Ayan George]

On Tue, Sep 25, 2012 at 12:29 PM, Jeff Rogers  wrote:
 >
 > 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.
 >
[snip!]
 >
 > Anything else to add?
 >

Can we:

* Allow c99 language features.
* Fully support HTTP 1.1
* Support configuring multiple servers using namespaces in the 
configuration file?

As far as development goes, can we move to git as the main way to 
maintain code and adopt more modern ways of submitting patches?

-ayan

--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Daniël Mantione]

Op Tue, 25 Sep 2012, schreef Jeff Rogers:


Anything else to add?


IPV6, please, please, please!

Seriously, lack of IPV6 support is the perfect excuse to phase out an 
AOLServer installation.


Depending on how long it will take to produce 4.6, maybe even consider a 
4.5 series release with ipv6, I have noticed any instabilities of my patch 
at least.


My patch: http://www.freepascal.org/~daniel/aolserver-ipv6support.diff

Daniël--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Wolfgang Winkler]

Hi!

Concerning websockets: I've written a tcl only solution for AOLserver 
which works very well for pushing data to thousands of clients. The only 
problem is the receiving end, as I've to poll all open sockets in 
[ns_chan -shared] because I don't get the events of the single sockets. 
If this worked, AOLserver would be the perfect tool for handling websockets.

Wolfgang

Am 2012-09-25 10:29, schrieb Jeff Rogers:
> 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


-- 
digital concepts OG
Software & Design
Landstrasse 68 / 5. Stock
A - 4020 Linz

Büro:  +43 732 99711772
Mobil: +43 699 19971172


--
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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[Sep Ng]

I say this half in jest but if tuning Aolserver can become less like black 
magic, that would be a huge plus!

On Tuesday, September 25, 2012 4:29:47 PM UTC+8, Jeff Rogers wrote:
>
> 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 
> aolserv...@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

Re: [AOLSERVER] Roadmap - 4.6 and beyond

[aT]

Great list Jeff !

Thanks for initiating this thread.



On Tue, Sep 25, 2012 at 12:29 PM, Jeff Rogers  wrote:

> 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
>



-- 
Syed Atif Ali
--
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