Personal tools
You are here: Home → Knowledge → Techie Central → OpenACS presentation → slide-13.html
Navigation
Log in


Forgot your password?
New user?
 
Document Actions

slide-13.html

Click here to get the file

Size 4.3 kB - File type text/html

File contents

<html>
<head>
  <title>AOLserver</title>
</head>
<body bgcolor="white">
<table width="100%">
  <tr>
    <td align="left"><h2>AOLserver</h2></td>
    <td align="right"><a href="slide-12.html">Prev</a> | <a href="slide-14.html">Next</a></td>
  </tr>
</table>
<hr>

<blockquote>

  Originally named the NaviServer Daemon, AOLserver began as a
  proprietary webserver back before most people knew much about the
  web.  This name still crops up in AOLserver as almost all AOLserver
  API's start with "ns_".<br/><br/>

  Most web professionals have never heard of AOLserver and swear by
  Apache or IIS.  For anyone who questions the usage of AOLserver,
  just think of what ISP put the first three letters in AOLserver, and
  no it wasn't Juno.<br/><br/>

  Since I have no familiarity with IIS, but tend to dismiss is as I
  have found Windows to be a totally insufficient server OS, I can
  only compare AOLserver with Apache.  It should be noted that when
  the decision to go with AOLserver was first made, Netscape numbered
  version 0.9, and Apache was not the 500-lb gorilla of webservers
  that it is today.  It should also be noted that some of the concerns
  have been resolved in the Apache 2.x system.<br/><br/>
 
  <table width="100%" border="1">
    <tr>
      <th>AOLServer</th>
      <th>Apache</th>
    </tr>
    <tr>
      <td>
      
        <blockquote>Answered requests by creating new threads thus
                    enabling it to easily scale up to higher numbers of
                    requests (since threads are easy to spawn and tear
                    down).  Multiple threads also allowed for better
                    sharing of data between requests.</blockquote>

      </td>
      <td>
        
        <blockquote>Until recently Apache used processes to answer
                    requests (this has changed with the 2.x series).
                    These were expensive to spawn and did not allow for
                    easy sharing of data.</blockquote>

      </td>
    </tr>
    <tr>

       <td>

         <blockquote>An embedded TCL interpreter allowed rapid
                     development of dynamic content for webpages.
                     This included a well-defined TCL API for working
                     with requests.</blockquote>

       </td>
       <td>
         
         <blockquote>The use of CGI to create dynamic webpages was
                     slow (as each request required the creation of a
                     new process), but allowed the use of many
                     different languages.  The eventual development of
                     FastCGI and the mod_*'s allowed increased
                     efficiency, but the integration was not
                     particularly tight and there was not a lot of
                     uniformity between the modules.</blockquote>

       </td>
    </tr>
    <tr>

      <td>

         <blockquote>A single DB API specification guaranteed
                     uniformity in communicating with databases.  The
                     pooling provided by the system allowed rapid and
                     efficient access to the databases since you
                     didn't have to spawn new threads or processes
                     every time you wanted to make a connection.  This
                     also guaranteed a maximum number of connections
                     to the database which prevented flooding
                     it.</blockquote>
                   
       </td>
       <td>

         <blockquote>No concept of database interactivity.  This was
                     provided by each of the individual modules.  Many
                     of the standard APIs (excepting JDBC and possibly
                     PERL DBI) are poorly designed.</blockquote>
     
       </td>

    </tr>
   </table>
   <br/>

   In an act of good faith I should mention that some of the things I
   mentioned as disadvantages, "loose integration with languages and
   databases" may be considered a good thing by some people.  It makes
   it easier for developers to choose their own solutions.  The choice
   is largely a matter of taste, and if I had started developing on
   Apache 2.x I might be more partial to Apache.  Perhaps as I use
   Apache more I will grow to love it as so many people do.


</blockquote>

<hr>
<a href="tristancohen@yahoo.com">tristancohen@yahoo.com</a>
</body>
</html>
by admin — last modified 2003-04-28 10:16
 

View My Stats