[geeklog-devel] Quick overview of GL2 and what we have so far and how it relates to the API

[Tony Bibbs]

I wanted to draw an ascii picture of what GL2 has started or planned so 
far.  Please take note as this impacts some of our discussions of late:

----------------------------------------------------------
|         | AUTHENTICATION/AUTHORIZATION |                |-->Module 1
| Geeklog | TRANSLATION                  | Plugin Manager |-->Module 2
|         | messaging*                   | (Includes API) |-->Module 3
|         | SESSION MANAGEMENT           |                |-->Module N
|         | database abstraction         |                |
|         | MVC                          |                |
|         | SPELLCHECKER                 |                |
|         | up2date service*             |                |
|         | module library interface     |                |
|         | remote bug reporting         |                |
|         | etc.                         |                |
-----------------------------------------------------------

NOTE: items in all CAPS have either been implemented or are being 
implemented.  Items marked with an * are items that would be for-profit 
or have extended for-profit features.

The diagram above isn't radically different from how GL 1.3.x works (I 
mean, we did do a lot of good stuff that shoud carry over).  First the 
big box containing the three sections is how we can logically think of 
Geeklog.  The middle tier are classes that I would provide a key 
resource to all modules.  The Plugin manager is the means by which 
Geeklog communicates to all the modules (the equivalent of 
lib-plugins.php in the 1.3.x world).

First off, Blaine, notice how I have made your messaging portion part of 
the core.  I know you don't want this but keep in mind this is a logical 
representation, not a physical on.  I plan on making your messaging 
component a true module.  The distinction is that I think you can almost 
gaurantee that nearly all modules will want the ability to use 
messaging.  Also, for clarity when I say messaging I a lumping PM, IM 
and Email functions all together.

Now let me bring your attention to the Plugin Manager.  This portion 
consists of two distinct pieces.  A) the server side manager responsible 
for calling API methods on the modules and B) the API itself that all 
modules must implement.

The API that vinny was talking about is item B) above.  I make this 
clarification because as I read through some of the feedback I saw us 
talking about things that aren't really meant to be in the API (note 
Vinny mentioned the same thing in his last message).  To be clear, the 
API should consist of methods that GL would want to all in order to 
invoke some sort of processing from a module.  On the flip side, the 
Plugin Manager will proxy requests between Geeklog and the modules (this 
IS a two way street).

That being said, we should probably be working on both the Module API 
*and* the object model for the Plugin Manager since they are so closely 
related.

On a side note, anything in lowercase has not been started yet.  If 
anybody wants to volunteer or any of those pieces please let me know.

Finally, I am hoping we find a new name for this other than "Geeklog". 
I know we have talked about this a lot but I wanted to bring this back 
up and challenge us to find a name that is a) catchy and b) marketable 
to businesses.

--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                  |
+----------------------------------------------------------------------+