Date: Sat May 18 18:37:22 CEST 2002
User: Derick Rethans
Directory: srmdoc/articles
Log Message:
[10.00]
- Rest of article
Modified files:
srmdoc/articles/php-almanac-2002.xml (version: 1.3)
[FILE: /srmdoc/articles/php-almanac-2002.xml]
--- srmdoc/articles/php-almanac-2002.xml:1.2 Fri May 10 07:29:35 2002 GMT
+++ srmdoc/articles/php-almanac-2002.xml Sat May 18 14:37:21 2002 GMT
@@ -18,9 +18,15 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date>21 Mar 2002</date>
+ <date>18 May 2002</date>
<authorinitials>Derick Rethans</authorinitials>
- <revremark>In progress</revremark>
+ <revremark>First version</revremark>
+ </revision>
+ <revision>
+ <revnumber>1.0.1</revnumber>
+ <date>18 May 2002</date>
+ <authorinitials>Derick Rethans, James Cox</authorinitials>
+ <revremark>Grammar/spelling fixes</revremark>
</revision>
</revhistory>
</articleinfo>
@@ -28,9 +34,10 @@
<section id="intro">
<title>Introduction</title>
<para>
- This article takes you on a tour to all functions that &srm.full; has to
+ This article takes you on a tour of all functions that &srm.full; has to
offer. In this section a history of the project is outlined and after that
- the different features are introduced.
+ the different features are introduced. Some of the functionality in this
+ article is not yet implemented, but will be in the near future.
</para>
<section id="intro.history">
@@ -39,7 +46,7 @@
&srm.small; was first conceived in the autumn of 2000. It is designed to
solve some of the problems often encountered with &php; and other web
scripting languages that result from the statelessness of the &http;
- protocol. Among the first ideas where implementing a &php; script which
+ protocol. Among the first ideas was to implement a &php; script which
should run 'in a loop' and handle all events. The job of this &php; script
was managing persistent resources to databases and other resources.
</para>
@@ -59,11 +66,11 @@
<para>
The first feature of &srm.small; is a module that can be used as a session
handler in &php; It works just like the 'files', 'mm' or 'pgsql' session
- handlers that are standard available, or the 'msession' session handler.
+ handlers that are available by default, or the 'msession' session handler.
The advantage of using an advanced, daemon based, approach for handling
session data that session data can be used in clustered environments far
more easier. The 'msession' module was specially written for this, but
- does not have the advantage that &srm.small; can offer; using session data
+ does not have the advantage that &srm.small; can offer: using session data
in <link linkend="overview.remote-objs">remote objects</link> just like it
would have been available to a normal script.
</para>
@@ -76,7 +83,7 @@
daemon, persistent across requests, scripts and even webservers. This
means that you can refer to this application data in in every script, from
everywhere. You can define namespaces for these application level
- variables as you see fit, so that it is possible to clearly seperate
+ variables as you see fit, so that it is possible to clearly separate
application level variables per application.
</para>
</section>
@@ -159,12 +166,12 @@
<section id="communication.standard">
<title>Standard Protocol</title>
<para>
- The standard protocol was the first implemented one. The protocol consists
+ This was the first implemented protocol, which consists
of a handshake in which protocol options are determined. Options for the
- protocal are the version of the protocol, whether <acronym
- title="Secure Socket Layer">SSL</acronym> is used or not. Also the session
- ID is generated in this stage. After this handshake data packets can be
- send over the established communication channel. Packets are structures of
+ protocal are: which version to use, and wheter <acronym
+ title="Secure Socket Layer">SSL</acronym> is enabled or not. Also the session
+ ID is generated in this stage. After this handshake, data packets can then be
+ sent over the established communication channel. Packets are structures of
SRM values, the native datatype within &srm.small;. SRM values are quite
analogous to the zval type that Zend uses for internal variable
representatations.
@@ -502,32 +509,156 @@
<title>&bananas;</title>
<para>
Bananas for &php; are a lot like Enterprise Beans for Java. They are
- objects written in &php; and 'live' inside the daemon.
+ objects written in &php; and 'live' inside the daemon and can be accessed
+ from client side scripts. They are fully persistent, and thus save state
+ and data between requests.
</para>
<section id="bananas.remote-objs">
<title>Remote objects</title>
<para>
+ Interaction with these remote objects from &srn.small; is just easy as
+ working with normal objects in PHP; on the daemon side you just write a
+ class that extends the Banana class, and add some bootstrap code to
+ instantiate the Banana in the script. Then you place this class into the
+ class directory as configured in srm.ini and your Banana can be accessed
+ from the clientside. The daemon does not even need to be restarted for
+ this, upgrading a Banana to a newer version can be done by replacing the
+ classfile in the class directory. All currently running Bananas of this
+ class should be terminated before they are reloaded from disk by the
+ daemon and before changes take effect. If you build in some sleep/wake-up
+ functionality in your Banana, you can preserve data between reloaded these
+ Bananas. In future versions of &srm.small; this will be done for you.
+ </para>
+ <para>
+ Below follows a PHP source file of a Banana class. It shows the following
+ functionality in Bananas: how to extend from the Banana base class; how to
+ use protected class members (read_proc); how to setup timers (clear_data);
+ the bootstrap code used to start up the Banana. The dependency on this
+ bootstrap code in the class file will very likely be removed in future
+ &srm.small; versions.
</para>
- </section>
-
- <section id="bananas.adt">
- <title>ADT</title>
<para>
+ <example>
+ <title>Basic implementation of a Banana class</title>
+ <programlisting role="php">
+<![CDATA[
+<?php
+
+ class system_info extends Banana
+ {
+ var $info;
+
+ function system_info()
+ {
+ $this->info = FALSE;
+ srm_protect ('read_proc');
+ srm_protect ('clear_data');
+ srm_timer ('clear_data', 600);
+ }
+
+ function clear_data()
+ {
+ $this->info = FALSE;
+ }
+
+ function read_proc()
+ {
+ if (!$this->info) {
+ $proc = file ('/proc/cpuinfo');
+ foreach ($proc as $entry) {
+ $data = preg_split ("/(\ )*:(\ )*/", $entry));
+ $this->info[trim($data[0])] = trim ($data[1]);
+ }
+ }
+ }
+
+ function get_cpu_speed()
+ {
+ $this->read_proc();
+ return $this->info['cpu Mhz'];
+ }
+ }
+
+ $si = new SystemInfo;
+ $si->run();
+?>
+]]>
+ </programlisting>
+ </example>
</para>
</section>
- <section id="bananas.timers">
- <title>Timed events</title>
+ <section id="bananas.application-session">
+ <title>Application and Session Bananas</title>
<para>
+ There are two classes of Bananas possible in &srm.small; , Bananas that
+ can be accessed from every script in every session, the Application Banana
+ (which was shown in all previous examples), and Bananas that only serve a
+ single session, the Session Banana. Instances of the latter class will be
+ removed from memory as soon as the session to which the Banana is linked
+ expires, along with the associated session data that has been stored in
+ the daemon for this session. Session Bananas can communicate with
+ Application Bananas, but for obvious reasons not with Session Bananas
+ belonging to a different session. Communcation between Bananas is done in
+ the same way as communication from a client side script with a Banana,
+ with the exception that you don't have to connect to the daemon.
+ </para>
+ <para>
+ With this interaction you can build very complex structures of
+ applications in which Application Bananas communicate with other
+ Application Bananas and where Session Bananas, or just client side scripts
+ interact with different parts of the the system.
</para>
</section>
- <section id="bananas.interaction">
- <title>Interaction between &bananas;</title>
- <para>
+
+ <section id="bananas.complex-data">
+ <title>Complex Data Structures</title>
+ <para>
+ Because Bananas are persistent in the daemon for a long time, they are
+ perfect to store large complex structures, for example a DOM
+ representation of a large XML document. By providing an API to this
+ document with class members in the Banana, the DOM document can be easily
+ modified without having to read, parse, modify and store it on each
+ request. This greatly increased performance of course.
+ </para>
+ <para>
+ Another application would be an API to a binary search tree which was
+ constructed with the almost finished ADT extension for PHP. This way the
+ tree doesn't need to be rebuild everytime a script is executed. Managing
+ complex data structures with &srm.small; like this makes a much easier and
+ abstracted API possible.
</para>
</section>
+ </section>
+
+ <section id="conclusion">
+ <title>Conclusion</title>
+ <para>
+ I hope you now have a better insight in &srm.small; 's functionality, and
+ have some clue in which situations SRM can be useful to you. The
+ application examples in this article shown only a portion of what you can
+ do, the rest is left to your imagination. If you have any questions
+ regarding this article or &srm.small;, feel free to write to the <ulink
+ url="http://www.vl-srm.net/doc/support.php#support.mailinglist">SRM
+ General Mailinglist</ulink> or visit the <ulink
+ url="http://www.vl-srm.net">website</ulink>
+ </para>
+ </section>
+
+ <section id="conclusion">
+ <title>Conclusion</title>
+ <para>
+ <ulink url="http://www.jdimedia.nl/derick/">Derick Rethans</ulink> provides
+ solutions for internet related problems. Working in his own company, he
+ has acquired vast experience with PHP related projects. He has contributed
+ in a number of ways to the PHP project, including the mcrypt extension,
+ bugfixes, additions and leading the QA team. In his spare time he likes to
+ work on SRM: Script Running Machine, watch movies and travel. He can be
+ reached at <ulink
+ url="mailto:d.rethans@jdimedia.nl">d.rethans@jdimedia.nl</ulink>.
+ </para>
</section>
</article>
<!-- keep this comment at the end of the file
Received on Sat May 18 19:30:23 2002
This archive was generated by hypermail 2.1.8 : Tue Jan 06 2009 - 12:00:02 CET