<?xml version='1.0' ?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
               "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % myvars SYSTEM "../variables.ent">
%myvars;
]>
<sect1 id="rp-requirements" xreflabel="OpenACS 4 Request Processor Requirements">
<title>Request Processor Requirements</title>


<authorblurb>
<para>By <ulink url="http://planitia.org">Rafael H. Schloming</ulink> </para>
</authorblurb>


<sect2 id="rp-requirements-intro">
<title>Introduction</title>


<para>The following is a requirements document for the OpenACS 4.0 request
processor. The major enhancements in the 4.0 version include a more
sophisticated directory mapping system that allows package pageroots to be
mounted at arbitrary urls, and tighter integration with the database to allow
for flexible user controlled url structures, and subsites.</para>

</sect2>

<sect2 id="rp-requirements-vision">
<title>Vision Statement</title>


<para>Most web servers are designed to serve pages from exactly one static
pageroot. This restriction can become cumbersome when trying to build a web
toolkit full of reusable and reconfigurable components.</para>

</sect2>

<sect2 id="rp-requirements-system-overview">
<title>System Overview</title>


<para>The request processor&#39;s functionality can be split into two main
pieces.</para>

<orderedlist>
<listitem>
<para>Set up the environment in which a server side script expects to run. This
includes things like:</para>

<itemizedlist>
<listitem>
<para>Initialize common variables associated with a request.</para>
</listitem>

<listitem>
<para>Authenticate the connecting party.</para>
</listitem>

<listitem>
<para>Check that the connecting party is authorized to proceed with the
request.</para>
</listitem>

<listitem>
<para>Invoke any filters associated with the request URI.</para>
</listitem>
</itemizedlist>

</listitem>

<listitem>
<para>Determine to which entity the request URI maps, and deliver the content
provided by this entity. If this entity is a proc, then it is invoked. If
this entitty is a file then this step involves determining the file type, and
the manner in which the file must be processed to produce content appropriate
for the connecting party. Eventually this may also require determining the
capabilities of the connecting browser and choosing the most appropriate form
for the delivered content.</para>
</listitem>
</orderedlist>

<para>It is essential that any errors that occur during the above steps be
reported to developers in an easily decipherable manner.</para>

</sect2>

<sect2 id="rp-requirements-links">
<title>Related Links</title>


<para><xref linkend="rp-design"/></para>

</sect2>

<sect2 id="rp-requirements-req">
<title>Requirements</title>


<para><emphasis role="strong">10.0 Multiple Pageroots</emphasis></para>

<blockquote>
<para><emphasis role="strong">10.10</emphasis> Pageroots may be combined into one URL space.</para>

<para><emphasis role="strong">10.20</emphasis> Pageroots may be mounted at more than one location in the URL
space.</para>
</blockquote>

<para><emphasis role="strong">20.0 Application Context</emphasis></para>

<blockquote>
<para><emphasis role="strong">20.10</emphasis> The request processor must be able to determine a primary context
or state associated with a pageroot based on it&#39;s location within the URL
space.</para>
</blockquote>

<para><emphasis role="strong">30.0 Authentication</emphasis></para>

<blockquote>
<para><emphasis role="strong">30.10</emphasis> The request processor must be able to verify that the connecting
browser actually represents the party it claims to represent.</para>
</blockquote>

<para><emphasis role="strong">40.0 Authorization</emphasis></para>

<blockquote>
<para><emphasis role="strong">40.10</emphasis> The request processor must be able to verify that the party the
connecting browser represents is allowed to make the request.</para>
</blockquote>

<para><emphasis role="strong">50.0 Scalability</emphasis></para>


</sect2>

</sect1>
