Difference between revisions of "Roadmap"

From AOLserver Wiki
Jump to navigation Jump to search
m (remove spam)
 
Line 1: Line 1:
−
The changing faces of Technology:
+
'''AOLserver 2005 Roadmap'''
  
−
A category of hardware and software that enables people to use the Internet as the transmission medium for telephone calls. For users who have free, or fixed-price Internet access, Internet telephony software essentially provides free telephone calls anywhere in the world. To date, however, Internet telephony does not offer the same quality of telephone service as direct telephone connections.
+
[[Jim Davidson]] has offered the following summary [http://listserv.aol.com/cgi-bin/wa?A2=ind0506&L=aolserver&P=6872] based on the ChangeLog that describes the changes going into AOLserver 4.5:
−
There are many Internet telephony applications available. Some, like CoolTalk and NetMeeting, come bundled with popular Web browsers. Others are stand-alone products. Internet telephony products are sometimes called IP telephony, Voice over the Internet (VOI) or Voice over IP (VOIP) products.  
 
  
 +
We should put a page on aolserver.com with some details.  We've moved
 +
the version to 4.5 from 4.1 to reflect the scope of changes.
 +
Scanning the ChangeLog and from what I can recall:
 +
* New connection management features including the ns_limits and
 +
ns_pools commands:
  
−
Interent Technology Links:
+
-- ns_limits: control # of threads executing and/or waiting for
−
* [[http://www.classytattoos.com/star-tattoos.php Star Tattoos]]                 
+
execution by method/URL
−
* [[http://www.classytattoos.com/tribal-tattoos.php Tribal Tattoos]]                   
+
 
−
* [[http://www.classytattoos.com/celebrity-tattoos.php Celebrity Tattoos]]                   
+
-- ns_pools: map method/URL's to specific thread pools
−
* [[http://www.classytattoos.com/butterfly-tattoos.php Butterfly Tattoos]]                   
+
 
−
* [[http://www.classytattoos.com/tattoo-removal.php Tattoo Remova]]                     
+
The idea is to use the two together, e.g., map slow-running db
−
* [[http://www.classytattoos.com/tattoos.php Tattoos]]                   
+
requests to specific pools and set limits to avoid overload. The
−
* [[http://www.dog-guide.org/ Dogs]]                    
+
result would be to trap cases where impatient folks press reload when
−
* [[http://www.dog-guide.org/dog-breeds.php Dog Breeds]]                   
+
things are slow, generating quick "try later" responses instead of
−
* [[http://www.dog-guide.org/dog-names.php Dog Names]]                   
+
gumming up the server.
−
* [[http://www.dog-guide.org/allergies-in-dogs.php Allergies in Dogs]]                    
+
* I/O features including:
−
* [[http://www.saunaguide.org/ Sauna]]                  
+
 
−
* [[http://www.saunaguide.org/home-sauna.php Home Sauna]]                   
+
-- A new "Ns_QueueWait" API to enable event-driven callbacks in the
−
* [[http://www.saunaguide.org/infra-red-sauna.php Infra Red Sauna]]                    
+
driver thread before dispatching to pools for processing.  The model
−
* [[http://www.saunaguide.org/sauna-benefits.php Sauna Benefits]]                   
+
is to augment data received from the client (headers, request,
−
* [[http://www.saunaguide.org/sauna-rooms.php Sauna Rooms]]                   
+
content) with additional data fetched over the network (likely stored
−
* [[http://www.teainfo.org/ Tea]]                    
+
in the new Ns_Cls "connection local storage" API's) before
−
* [[http://www.teainfo.org/green-tea.php Green Tea]]                    
+
dispatching to the connection threads. An example would be to add
−
* [[http://www.teainfo.org/tea-gardner.php Tea Gardner]]
+
certain personalization data received via a web service. The
 +
rationale here is that I/O events are cheap so do those upfront
 +
instead of having expensive connection threads burdened with wasteful
 +
blocking I/O. This is a somewhat obscure and technical interface.
 +
 
 +
-- Ability to manage larger file uploads by spooling to a temp file.
 +
This keeps many of the useful functions folks utilize from working
 +
for these large files, in particular auto-parsing of input available
 +
via ns_conn form, but is available for custom apps willing to deal
 +
with the complexity.
 +
* ADP improvements including:
 +
 
 +
-- A new execution caching technique at the ns_adp_include level
 +
which allows you to save the results of execution of an included ADP
 +
(and includes below that) for reuse on subsequent connections up to a
 +
specified time.  Embedded ns_adp_include's with the -nocache flag at
 +
lower levels allow you to still execute dynamic code within cached
 +
blocks if necessary.  The goal is to improve performance of pages
 +
which are nearly dynamic, i.e., pages where underlying data really
 +
isn't personalized but instead may change every few minutes or so.
 +
We prototyped this technique at AOL for an app which had these
 +
characteristics and drove transaction throughput from less than 50/
 +
second to well over 400 while still maintaining certain personalized
 +
features of the page.
 +
 
 +
-- New "singlescript" config option which turns ADP pages into a
 +
single script enabling syntax such as "<% foreach e $list { %>
 +
element <%= $e %> here <% } %>" and treating an error anywhere on the
 +
pages as an error for the full page. Evidently this is more similar
 +
to other execution environments such as JSP. It's a matter of
 +
opinion whether this is a better or worse approach to ADP execution -
 +
the default is off.
 +
* Output buffer improvements via new Ns_ConnFlush:
 +
 
 +
-- Automatic UTF-8 to output charset encoding
 +
 
 +
-- Gzip compression
 +
 
 +
-- Streaming output in chunked-encoding format instead of the
 +
previous "response with no length" HTTP/1.0 method.
 +
 
 +
Much of the code for Ns_ConnFlush was previously private to ADP.  ADP
 +
has been modified to use Ns_ConnFlush and will also automatically
 +
switch into streaming mode when output buffer limits are exceeded
 +
(the previous behavior is to simply keep buffering without limit).
 +
Ns_ConnFlush could be useful to simplify and standardize output from
 +
other execution environments as well, e.g., PHP and Java servlets.
 +
* Tcl improvements including:
 +
 
 +
-- Cleaned up and well commented core code so folks can understand
 +
the arcane config/resource management approach of Tcl within AOLserver.
 +
 
 +
-- A new Ns_TclRegisterTrace API to enable callbacks at key state
 +
transition points in a much more natural way. The ns_ictl command
 +
has been updated to support script-level traces.
 +
* A new Ns_Task API designed to replace the old Ns_SockCallback API
 +
which didn't do a very good job at managing timeouts along with I/O
 +
events.  The ns_http command has been modified to use Ns_Task (the
 +
old Ns_SockCallback-based ns_http is also still available via
 +
configuration for the paranoid).
 +
* Numerous bug fixes.
 +
 
 +
 
 +
Unfortunately, no comprehensive list is maintained of these changes
 +
and the documentation is not yet up to date.  Actually, the
 +
documentation hasn't been up to date since version 2.3 which is a
 +
great disappointment for me.  However, the ChangeLog has been
 +
maintained quite well so it's possible to get an overview of the
 +
various bug fixes and other minor updates from there.
 +
 
 +
Dossy and Zoran may recall other new features as they've been active
 +
on the release as well.  Overall, I believe we're done with 4.5 and
 +
should tag it, complete the documentation, produce some quality
 +
release notes, and move on to 5.0.
 +
 
 +
----
 +
 
 +
'''AOLserver project 2004 Roadmap'''
 +
 +
This document will serve as the roadmap for the AOLserver project and Open Source community for 2004.
 +
 +
N.B.:  There is no designation whether any of the tasks necessary to complete items on the roadmap must be performed by an AOL employee or someone from the larger AOLserver community.  Ideally, tasks will be completed by whoever is enthusiastic about the work, has the necessary time to commit to completing it as well as the capability.  There is no explicit limit to the amount of contribution that can come from any participant in the project.
 +
 
 +
----
 +
 
 +
'''Goals and milestones for Q3 2004'''
 +
 
 +
'''1)  Feature roadmap for AOLserver through 2004 and into 2005'''
 +
 
 +
In order to enable the Open Source community to better participate, it is important that we have a clear list of [[Features]] that should be worked on.
 +
 
 +
----
 +
 +
'''Goals and milestones for Q2 2004'''
 +
 +
'''1)  www.aolserver.com website revamp'''
 +
 
 +
The project website deserves a more modern look and feel while maintaining the crisp, clean design aspects of the site.  The site needs to clearly represent the most current releases and recent changes.
 +
 
 +
Specific information that should be easily accessible on the website initially:
 +
* what it is
 +
* how it's different
 +
* where is useful, where it's not
 +
* how to get started - basic guide, notes for apache users
 +
* latest source and binary bundles
 +
* basic intro docs and extensive, complete, accurate manpages
 +
 
 +
''Update on 6/25: aolserver.org and aolserver.net should both point to aolserver.com by the week of 6/28.''
 +
 
 +
----
 +
 
 +
'''2)  Freshen up documentation'''
 +
 
 +
Currently available documentation for AOLserver mixes information for 2.3, 3.x and 4.x.  All of the documentation needs to be evaluated for correctness and updated where appropriate.  Documentation should be made available in at least three formats: plain text, HTML and PDF.  All documentation should be readily available from the project website. 
 +
 
 +
The goal is to have a list of all documentation, both what exists and what we still need, by 5/26.  From there, the plan is to spend the next 4 weeks verifying or updating documentation.  Targeting 6/25 to have documentation for AOLserver 4.0 complete.
 +
 
 +
''Update on 6/25:  [[Tcl API]] effort: 142 out of 228 commands or 62% complete.  Work on the [[Tutorials]] and HOWTO sections have also begun.  See the [[Documentation]] page for more.''
 +
 
 +
----
 +
 
 +
'''3)  SourceForge bug and support trackers'''
 +
 
 +
There are currently 56 open bugs, 3 open support requests, 29 open patches and 8 open feature requests in SourceForge.  Attention to these trackers is minimal at best which sends the wrong message about the project's commitment to supporting itself. 
 +
 
 +
The current goal is to ensure that opened requests get assigned to someone within 24-48 hours and resolved in a reasonable timeframe.  Resolutions for common problems should be properly documented and published appropriately.
 +
 
 +
''Update on 6/25: 78 open bugs, 4 open support tickets, 37 open patches, 14 open feature requests.''
 +
 
 +
''Update on 7/2:  Bugs: 78 > 39 (-39 / -50%). Support Requests: 4 > 2 (-2 / -50%). Patches: 39 > 37 (-2 / -5%).  RFEs: 14 > 16 (+2 / +13%).  Current open bug breakdown by year: 2001 (7), 2002 (4), 2003 (20), 2004 (8).''
 +
 
 +
''Update on 7/9:  Bugs: 39 > 66 (+27 / +41%).  Support Requests: 2 > 3 (+1 / 33%).  RFEs: 16 > 56 (+40 / +71%).  Current open bug breakdown: 2001 (8), 2002 (7), 2003 (24), 2004 (10).  The "Patches" tracker at SourceForge has been retired.''
 +
 
 +
''Update on 7/16:  Bugs: 66 > 44 (-22 / -33%).  Support Requests: 2 > 2 (0 / NC). RFEs: 56 > 40 (-16 / -28%).  Current open bug breakdown: 2001 (8), 2002 (5), 2003 (20), 2004 (11).''
 +
 
 +
''Update on 7/23:  Bugs: 44 > 47 (+3 / 6%).  Support Requests: 2 > 2 (0 / NC).  RFEs: 40 > 41 (+1 / 2%).  Current open bug breakdown: 2001 (8), 2002 (5), 2003 (19), 2004 (15).''
 +
 
 +
''Update on 9/1:  Bugs: 41.  Support Requests: 0.  Feature Requests: 49.  Current open bug breakdown: 2001 (7), 2002 (4), 2003 (13), 2004 (17).''
 +
 
 +
----
 +
 
 +
'''4)  Better release management of AOLserver'''
 +
 
 +
While maintaining a ChangeLog and tagging code periodically may be suitable for the developer community, the larger user audience of AOLserver has a varying degree of technical background. Releases need to be managed such that a clear communication accessible to a non-technical background should be able to understand the value contained in the latest code release providing clear and compelling reasons to keep their installations up to date.  This same information should also be be published on the project website as well as distributed to the AOLSERVER-ANNOUNCE mailing list.
 +
 
 +
We need to ensure that changes since the previous release will be collated and prepared along with the actual code release, then published on the wiki and the aolserver.com website.  Official releases will be published in source and binary form (when applicable) on the project website via the Project Files section in SourceForge.  An update to the AOLserver project record on Freshmeat.net should also be done.
 +
 
 +
''Update on 7/16:  With the bug that slipped into the 4.0.6 release, it's obvious that even a simple automated test suite would prove useful.  With that, it's time to start documenting: [[How are releases tested]].''
 +
 
 +
Release announcements:
 +
* 07 Sep 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0409&L=aolserver-announce&P=66 AOLserver 4.0.8]
 +
* 19 Jul 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0407&L=aolserver-announce&P=163 AOLserver 4.0.7]
 +
* 16 Jul 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0407&L=aolserver-announce&P=61 AOLserver 4.0.6]
 +
* 07 Jun 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0406&L=aolserver&P=4884 AOLserver 4.0.5]
 +
* 26 Mar 2004: AOLserver 4.0.3
 +
* 23 Nov 2003: AOLserver 4.0.2
 +
* 20 Nov 2003: AOLserver 4.0.1
 +
* 03 Nov 2003: AOLserver 4.0.0
 +
 
 +
----
 +
 
 +
'''5)  Establish metrics for measuring success and publish reports on a regular basis'''
 +
 
 +
There are several simple measurements that we can take that can be automated on a regular schedule (daily, weekly, monthly) and published on the project website.  The first metric will be:
 +
 
 +
Commit frequency per username: number of files affected, lines of code affected.
 +
 
 +
This serves the purpose of making clear to the community where activity is taking place within the project as well as which individuals are actively involved and participating.  Without this, it is unclear from a high level what kind of progress is being made on the project, if any at all, giving people a sense that the project is inactive when that may not actually be the case.  Having this metric measured regularly and published will either confirm or dispel this belief and allow us to better manage this issue.
 +
 
 +
''Update on 7/9:  The first [http://article.gmane.org/gmane.comp.web.aolserver/10810 CVS commit stats for June 2004] were posted to the AOLserver mailing list.''
 +
 
 +
''Update on 9/1:  CVS commit stats for [http://article.gmane.org/gmane.comp.web.aolserver/11299 July 2004] and [http://article.gmane.org/gmane.comp.web.aolserver/11300 August 2004] have been posted to the AOLserver mailing list.''
 +
 
 +
----
 +
 
 +
'''6)  Regular and open communications to the world'''
 +
 
 +
In order to raise awareness about AOLserver to both attract users and developers, we need regular and open communication with the world.  The messages need to be clear, concise and accessible to a wide audience.  They need to be sent out regularly to keep the attention of our audience as well as to show steady progress.   
 +
 
 +
----
 +
 
 +
'''7)  Tighter integration of Java into the core execution environment'''
 +
 
 +
With tighter Java integration into AOLserver, we will be able to leverage more available talent as well as more third-party developed software under AOLserver.  There are several efforts to bring Java into AOLserver but the project could benefit from having these separate efforts aligned and deliver a single solution.
 +
 
 +
Currently, the [[nsjk2]] module is under active development, especially at AOL, for supporting Java/Tomcat with AOLserver.
 +
 
 +
----
 +
 
 +
'''8)  Win32 platform becomes a first-class citizen again'''
 +
 
 +
While even the more recent releases of AOLserver can still be built on Win32, the commitment of official support for it was left to the community to resolve.  Consider this the resolution: the audience for AOLserver on Win32 should not be diminished without good reason.
 +
 
 +
''Update on 7/22:  The availability of [http://article.gmane.org/gmane.comp.web.aolserver/10927 experimental Win32 binaries] of AOLserver 4.0.7 was sent to the mailing list. Links to downloads are on the [[Downloads]] page.''

Latest revision as of 17:15, 5 January 2006

AOLserver 2005 Roadmap

Jim Davidson has offered the following summary [1] based on the ChangeLog that describes the changes going into AOLserver 4.5:

We should put a page on aolserver.com with some details. We've moved the version to 4.5 from 4.1 to reflect the scope of changes. Scanning the ChangeLog and from what I can recall:

  • New connection management features including the ns_limits and

ns_pools commands:

-- ns_limits: control # of threads executing and/or waiting for execution by method/URL

-- ns_pools: map method/URL's to specific thread pools

The idea is to use the two together, e.g., map slow-running db requests to specific pools and set limits to avoid overload. The result would be to trap cases where impatient folks press reload when things are slow, generating quick "try later" responses instead of gumming up the server.

  • I/O features including:

-- A new "Ns_QueueWait" API to enable event-driven callbacks in the driver thread before dispatching to pools for processing. The model is to augment data received from the client (headers, request, content) with additional data fetched over the network (likely stored in the new Ns_Cls "connection local storage" API's) before dispatching to the connection threads. An example would be to add certain personalization data received via a web service. The rationale here is that I/O events are cheap so do those upfront instead of having expensive connection threads burdened with wasteful blocking I/O. This is a somewhat obscure and technical interface.

-- Ability to manage larger file uploads by spooling to a temp file. This keeps many of the useful functions folks utilize from working for these large files, in particular auto-parsing of input available via ns_conn form, but is available for custom apps willing to deal with the complexity.

  • ADP improvements including:

-- A new execution caching technique at the ns_adp_include level which allows you to save the results of execution of an included ADP (and includes below that) for reuse on subsequent connections up to a specified time. Embedded ns_adp_include's with the -nocache flag at lower levels allow you to still execute dynamic code within cached blocks if necessary. The goal is to improve performance of pages which are nearly dynamic, i.e., pages where underlying data really isn't personalized but instead may change every few minutes or so. We prototyped this technique at AOL for an app which had these characteristics and drove transaction throughput from less than 50/ second to well over 400 while still maintaining certain personalized features of the page.

-- New "singlescript" config option which turns ADP pages into a single script enabling syntax such as "<% foreach e $list { %> element <%= $e %> here <% } %>" and treating an error anywhere on the pages as an error for the full page. Evidently this is more similar to other execution environments such as JSP. It's a matter of opinion whether this is a better or worse approach to ADP execution - the default is off.

  • Output buffer improvements via new Ns_ConnFlush:

-- Automatic UTF-8 to output charset encoding

-- Gzip compression

-- Streaming output in chunked-encoding format instead of the previous "response with no length" HTTP/1.0 method.

Much of the code for Ns_ConnFlush was previously private to ADP. ADP has been modified to use Ns_ConnFlush and will also automatically switch into streaming mode when output buffer limits are exceeded (the previous behavior is to simply keep buffering without limit). Ns_ConnFlush could be useful to simplify and standardize output from other execution environments as well, e.g., PHP and Java servlets.

  • Tcl improvements including:

-- Cleaned up and well commented core code so folks can understand the arcane config/resource management approach of Tcl within AOLserver.

-- A new Ns_TclRegisterTrace API to enable callbacks at key state transition points in a much more natural way. The ns_ictl command has been updated to support script-level traces.

  • A new Ns_Task API designed to replace the old Ns_SockCallback API

which didn't do a very good job at managing timeouts along with I/O events. The ns_http command has been modified to use Ns_Task (the old Ns_SockCallback-based ns_http is also still available via configuration for the paranoid).

  • Numerous bug fixes.


Unfortunately, no comprehensive list is maintained of these changes and the documentation is not yet up to date. Actually, the documentation hasn't been up to date since version 2.3 which is a great disappointment for me. However, the ChangeLog has been maintained quite well so it's possible to get an overview of the various bug fixes and other minor updates from there.

Dossy and Zoran may recall other new features as they've been active on the release as well. Overall, I believe we're done with 4.5 and should tag it, complete the documentation, produce some quality release notes, and move on to 5.0.

AOLserver project 2004 Roadmap

This document will serve as the roadmap for the AOLserver project and Open Source community for 2004.

N.B.: There is no designation whether any of the tasks necessary to complete items on the roadmap must be performed by an AOL employee or someone from the larger AOLserver community. Ideally, tasks will be completed by whoever is enthusiastic about the work, has the necessary time to commit to completing it as well as the capability. There is no explicit limit to the amount of contribution that can come from any participant in the project.

Goals and milestones for Q3 2004

1) Feature roadmap for AOLserver through 2004 and into 2005

In order to enable the Open Source community to better participate, it is important that we have a clear list of Features that should be worked on.

Goals and milestones for Q2 2004

1) www.aolserver.com website revamp

The project website deserves a more modern look and feel while maintaining the crisp, clean design aspects of the site. The site needs to clearly represent the most current releases and recent changes.

Specific information that should be easily accessible on the website initially:

  • what it is
  • how it's different
  • where is useful, where it's not
  • how to get started - basic guide, notes for apache users
  • latest source and binary bundles
  • basic intro docs and extensive, complete, accurate manpages

Update on 6/25: aolserver.org and aolserver.net should both point to aolserver.com by the week of 6/28.

2) Freshen up documentation

Currently available documentation for AOLserver mixes information for 2.3, 3.x and 4.x. All of the documentation needs to be evaluated for correctness and updated where appropriate. Documentation should be made available in at least three formats: plain text, HTML and PDF. All documentation should be readily available from the project website.

The goal is to have a list of all documentation, both what exists and what we still need, by 5/26. From there, the plan is to spend the next 4 weeks verifying or updating documentation. Targeting 6/25 to have documentation for AOLserver 4.0 complete.

Update on 6/25: Tcl API effort: 142 out of 228 commands or 62% complete. Work on the Tutorials and HOWTO sections have also begun. See the Documentation page for more.

3) SourceForge bug and support trackers

There are currently 56 open bugs, 3 open support requests, 29 open patches and 8 open feature requests in SourceForge. Attention to these trackers is minimal at best which sends the wrong message about the project's commitment to supporting itself.

The current goal is to ensure that opened requests get assigned to someone within 24-48 hours and resolved in a reasonable timeframe. Resolutions for common problems should be properly documented and published appropriately.

Update on 6/25: 78 open bugs, 4 open support tickets, 37 open patches, 14 open feature requests.

Update on 7/2: Bugs: 78 > 39 (-39 / -50%). Support Requests: 4 > 2 (-2 / -50%). Patches: 39 > 37 (-2 / -5%). RFEs: 14 > 16 (+2 / +13%). Current open bug breakdown by year: 2001 (7), 2002 (4), 2003 (20), 2004 (8).

Update on 7/9: Bugs: 39 > 66 (+27 / +41%). Support Requests: 2 > 3 (+1 / 33%). RFEs: 16 > 56 (+40 / +71%). Current open bug breakdown: 2001 (8), 2002 (7), 2003 (24), 2004 (10). The "Patches" tracker at SourceForge has been retired.

Update on 7/16: Bugs: 66 > 44 (-22 / -33%). Support Requests: 2 > 2 (0 / NC). RFEs: 56 > 40 (-16 / -28%). Current open bug breakdown: 2001 (8), 2002 (5), 2003 (20), 2004 (11).

Update on 7/23: Bugs: 44 > 47 (+3 / 6%). Support Requests: 2 > 2 (0 / NC). RFEs: 40 > 41 (+1 / 2%). Current open bug breakdown: 2001 (8), 2002 (5), 2003 (19), 2004 (15).

Update on 9/1: Bugs: 41. Support Requests: 0. Feature Requests: 49. Current open bug breakdown: 2001 (7), 2002 (4), 2003 (13), 2004 (17).

4) Better release management of AOLserver

While maintaining a ChangeLog and tagging code periodically may be suitable for the developer community, the larger user audience of AOLserver has a varying degree of technical background. Releases need to be managed such that a clear communication accessible to a non-technical background should be able to understand the value contained in the latest code release providing clear and compelling reasons to keep their installations up to date. This same information should also be be published on the project website as well as distributed to the AOLSERVER-ANNOUNCE mailing list.

We need to ensure that changes since the previous release will be collated and prepared along with the actual code release, then published on the wiki and the aolserver.com website. Official releases will be published in source and binary form (when applicable) on the project website via the Project Files section in SourceForge. An update to the AOLserver project record on Freshmeat.net should also be done.

Update on 7/16: With the bug that slipped into the 4.0.6 release, it's obvious that even a simple automated test suite would prove useful. With that, it's time to start documenting: How are releases tested.

Release announcements:

5) Establish metrics for measuring success and publish reports on a regular basis

There are several simple measurements that we can take that can be automated on a regular schedule (daily, weekly, monthly) and published on the project website. The first metric will be:

Commit frequency per username: number of files affected, lines of code affected.

This serves the purpose of making clear to the community where activity is taking place within the project as well as which individuals are actively involved and participating. Without this, it is unclear from a high level what kind of progress is being made on the project, if any at all, giving people a sense that the project is inactive when that may not actually be the case. Having this metric measured regularly and published will either confirm or dispel this belief and allow us to better manage this issue.

Update on 7/9: The first CVS commit stats for June 2004 were posted to the AOLserver mailing list.

Update on 9/1: CVS commit stats for July 2004 and August 2004 have been posted to the AOLserver mailing list.

6) Regular and open communications to the world

In order to raise awareness about AOLserver to both attract users and developers, we need regular and open communication with the world. The messages need to be clear, concise and accessible to a wide audience. They need to be sent out regularly to keep the attention of our audience as well as to show steady progress.

7) Tighter integration of Java into the core execution environment

With tighter Java integration into AOLserver, we will be able to leverage more available talent as well as more third-party developed software under AOLserver. There are several efforts to bring Java into AOLserver but the project could benefit from having these separate efforts aligned and deliver a single solution.

Currently, the nsjk2 module is under active development, especially at AOL, for supporting Java/Tomcat with AOLserver.

8) Win32 platform becomes a first-class citizen again

While even the more recent releases of AOLserver can still be built on Win32, the commitment of official support for it was left to the community to resolve. Consider this the resolution: the audience for AOLserver on Win32 should not be diminished without good reason.

Update on 7/22: The availability of experimental Win32 binaries of AOLserver 4.0.7 was sent to the mailing list. Links to downloads are on the Downloads page.

Retrieved from "https://panoptic.com/mediawiki/aolserver/index.php?title=Roadmap&oldid=4667"