[geeklog-devel] Geeklog 2: it has a pulse!

[Tony Bibbs]

Ok, granted it isn't rocket science but it is, in fact, a start.  Please 
bare with me and read this it it's entirety.

Go here:

http://project.geeklog.net/~tony/

There you will see a very simple login box with account information 
below it on how to get in.  Once you log in you are presented with a 
link that will take you to a page that will dump out a bunch of session 
data.

Here is what is happening:

1) When you hit submit, a request for authentication is built in the 
form of an XML string.  This XML string contains:
     - Application ID
     - Username
     - Password
     - Command Name (in this case authenticate)

2) Server receives the request and sends it to the command factory which 
recognizes the XML request as an authentication request.  It then 
instantiates (on the fly) an instance of the authenticate command and 
tells it to execute.

3) Authenticate command then passes the application ID to the provider 
factory to determine which data provider to authenticate against.  In 
this case it builds an instance of the SQLProvider class and executes 
the authenticate method.

4) SQLProvider authenticates user, gets any group and permissions tied 
to the user and returns the results back to the authenticate command.

5) Authenticate command then builds an XML response and sends it back to 
calling application.

6) The client receives the response, parses it into a User object and 
saves it to the session (which is stored in the database). It then shows 
you the link to a new page.

7) new page pulls the user object from the session with a single DB call 
and outputs a few attributes on the user.

To be clear this establishes a few things:

a) we now have an A&A service which can service many applications to 
implement a single credential set.  This makes the prospect of tying 
other applications in easy encouraging 3rd party apps to work with GL2

b) service can run on a separate box from GL or (as in this case) on 
same box.

c) user data is persisted to a database using PHP4 sessions effectively 
rendering all the code that use to be in lib-sessions.php useless 
(saving, restoring and garbage collection is done for us by PHP)

d) succesfully pulled a PHP OO user object from the session with a 
single database hit.  If you recall in GL 1.3.x you have to sometime hit 
2 or 3 tables often with independent queries against user, user_index, 
user_prefs, etc in order to re-establish session.  Now you do it with 
one DB call that you don't even make (PHP4 session handler pulls it for 
us when you call session_start).

You can browse the code on our cvs server here:

http://cvs.geeklog.net/chora/cvs.php/geeklog-2

There is still a lot of work to do.  I'd like to convert one of the 
service methods to use SOAP just to see how much easier that will simply 
  the code (with SOAP I don't have to build and parse XML which also 
removes the requirement having xml support compiled into PHP).  If that 
tests out Ok and if timing benchmarks both on the same server and on 
separate servers is acceptable I will convert it over.

However, in the meantime, we need to start concentrating on 
localization.  Handling language effectively as well as time/currency 
stuff will be key and, frankly, we can't go anywhere else without 
getting that done.  Marc, if I get you a template for a detailed 
requirements document do you think you could get it started for us?  By 
them time you get a draft of that I should have this code stable enough 
to start divying up work immediately.

--Tony


-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+