[srm-cvs] CVS Update: - Corrected more documentation.

Date: Mon Feb 18 00:33:22 CET 2002
User: Dan Kalowsky
Directory: srmdoc/user

Log Message:
 [0.70]
 - Corrected more documentation.
 # This needs to be double checked for factual accuracy.
 # I also don't like the last paragraph completely...
 # ALSO THERE NEEDS TO BE MORE CONSISTENCY IN THE SRM SYSTEM. If we're
 # calling things Banana's lets call them Banana's and not SRMApps :)
 
Modified files:
           srmdoc/user/features.xml (version: 1.3)

[FILE: /srmdoc/user/features.xml]

--- srmdoc/user/features.xml:1.2 Sat Feb 09 22:48:57 2002 GMT
+++ srmdoc/user/features.xml Sun Feb 17 22:33:21 2002 GMT
@@ -7,12 +7,12 @@
  </para>
 
  <section id="features.session-handler">
- <title>SRM as session handler</title>
+ <title>SRM as a session handler</title>
   <para>
    This is the first implemented feature, and should be gamma quality. It works
- just like the 'files', 'mm' or 'pgsql' session handler. The only thing you
- need to do is change session.save_handler in php.ini . At this moment the
- location is hardcoded (a shame, but an easy fix). It defaults to
+ just like the 'files', 'mm' or 'pgsql' session handler. To enable this
+ feature, edit the php.ini entry for session.save_handler. At the moment,
+ the location is hardcoded (a shame, but an easy fix). It defaults to
    'localhost'.
   </para>
  </section>
@@ -24,24 +24,26 @@
    <orderedlist>
     <listitem>
      <para>
- The remote function is defined in a module, written in C. For example
- from the standard module: <function>get_function_list</function> or
- <function>get_application_keys</function>. The module API is quite easy
- (easier than PHP modules), and it should therefore not be a problem to
- add other modules. One of the included modules is the 'auth' module,
- which makes it possible to authenticate users with PAM, password files,
- or for example a Challenge-Response protocol (this last one is finished,
- but it should be merged into the auth module).
+ <!-- This really makes no sense whatsoever can someone please please
+ please decrypt the meaning to this for me? - Dan -->
+ Remote function defined within an external SRM module. For example the
+ standard module contains the calls <function>get_function_list</function>
+ and <function>get_application_keys</function>. The SRM module API is
+ simplistic and should pose no problem for adding other modules. One of
+ the included modules, the 'auth' module, adds authentication support
+ through the use of PAM, password files, or a Challenge-Response protocol.
+ At the time of this writing the Challenge-Response protocol system is
+ not merged into the auth module.
      </para>
     </listitem>
 
     <listitem>
      <para>
- Functions defined in PHP function libraries. PHP function libraries are
- loaded at startup of the daemon. The PHP scripts that are part of this
- library get compiled and executed. Because the compiled scripts are not
- destroyed after that, it is possible to call them from a client side PHP
- script again, without having to parse/compile them.
+ Functions defined in PHP function libraries. PHP function libraries are
+ loaded at startup of the daemon. All PHP scripts contained within the
+ library are compiled and executed. Because the compiled scripts are not
+ destroyed, it is possible to call them from a client side PHP script
+ at a later time without having to re-parse/re-compile them.
      </para>
     </listitem>
    </orderedlist>
@@ -63,9 +65,12 @@
  <section id="features.application-vars">
   <title>Application level variables</title>
   <para>
- Application level variables are variables stored in the SRM daemon,
- persistent across requests. This means that you can use these in every
- script, using them is very easy:
+ An application level variable is the name given to data stored within the
+ SRM daemon, and can persist across mutliple client requests. This means
+ it is possible to use these variables in every script. These variables
+ are stored in the SRM objects' globals array, and can be accessed by
+ directly requesting the specific value. An example showing how to access
+ and set these variables can be found below:
   </para>
   <para>
    <programlisting>&lt;?php
@@ -76,8 +81,10 @@
    </programlisting>
   </para>
   <para>
- Namespaces should be implemented here, so that you can have application
- variables for every different application you have.
+ Due to the nature of storing these arrays, it is suggested that a user
+ implement a system of namespaces for sanitys sake. Namespacing will allow
+ a user to have specific application variables on a per application basis
+ without having to worry about if a name has already been used.
   </para>
  </section>
 
@@ -86,8 +93,8 @@
   <para>
    Remote objects are PHP scripts, running permanently in the SRM Daemon. We
    call these remote objects <classname>SRMApp</classname>s, or
- <classname>Banana</classname>s. You can instatiate them just like a normal
- object, as is done in this example:
+ <classname>Banana</classname>s. A Banana can be instatiated just like a
+ normal object, as is shown in this example:
   </para>
   <para>
    <programlisting>&lt;?php
@@ -97,8 +104,8 @@
    </programlisting>
   </para>
   <para>
- You now can use the <varname>$uptime</varname> object like a normal PHP
- object, with the exception that it is run remotely.
+ It is now possible to use the <varname>$uptime</varname> object like a
+ normal PHP object, with the exception that it is run remotely.
   </para>
  </section>
 </chapter>
Received on Mon Feb 18 00:25:42 2002