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

[Tony Bibbs]

Yeah, but if you start depending on files then it makes having GL2 work 
on multiple webservers more difficult.  Let me think about this some more.

--Tony

Vincent Furia wrote:

> My idea was to store who registered which events in the database.  But, 

> thinking ahead, since event registration is not a frequent task (and 

> therefore the table won't be changing all that much) I think we could 

> easily use a php file as a cache.  The php file would get updated 

> everytime the event_handler table was altered.  This would prevent 

> unnecessary database calls.

> 

> The cache file could look something like:

> <?php

> $eventListener['plugin']['event'][] = 'listening plugin';

> ?>

> 

> And then once this file is loaded, and GL2 core gets notified of an 

> event, all it has to do is:

> foreach ($eventListener[$plugin][$event] as $plugs) {

>    require_once($plugs . '/functions.inc');    // or whatever file...

>    $plugs::onEvent($plugin, $event, $vars);

> }

> 

> The only problem I see with the method you suggest is that every 

> plugin's functions.inc file (or whatever the equivilent we will use in 

> GL2) will have to be loaded whenever any event occurs.  The method 

> recommended above, would only need to load the plugins that are 

> listening for an event.  Since I expect many more events to occur than 

> are actually going to be handled by the different plugins, this will 

> probably end up saving CPU and Memmory usage.  It will allow us to stick 

> with the MVCnPHP mantra of loading only what is necessary.

> 

> -Vinny

> 

> Tony Bibbs wrote:

> 

>> I need more time to digest this but one quick note about your approach 

>> to event handling.  If I read it right, your method requires trip(s) 

>> to the database to be able to determine which modules wanted to be 

>> triggered when an event occurs.  I would like to see us implement this 

>> in a way that would avoid that overhead and I think we can do it.  For 

>> example, a module will know when it is shipped which modules it will 

>> try to interact with.  Here is a snippet that I think can handle this:

>>

>> /**

>> * This calls an event on any module

>> *

>> * NOTE: this is just a stub in the API

>> *

>> * @param string $eventName Name of the event that was fired

>> * @param string $module Name of the module that triggered an event

>> * @param array $args Array of arguments for the handler

>> *

>> */

>> function handleEvent($eventName, $module, $args)

>> {

>> }

>>

>> For example purposes let's assume the following is the API 

>> implementation of the function above for the forum module:

>>

>> /**

>> * Proxies events to the appropriate non-API event handlers

>> *

>> *

>> * @param string $eventName Name of the event that was fired

>> * @param string $module Name of the module that triggered an event

>> * @param array $args Array of arguments for the handler

>> *

>> */

>> function handleEvent($eventName, $module, $args)

>> {

>>     switch ($module) {

>>         'Geeklog':

>>             // Call local non-API method to handle Messaging event

>>             return handleGeeklogEvent($eventName);

>>         'Messaging':

>>             // Call local non-API method to handle Messaging event

>>             return handleMessagingEvent($eventName);

>>         'Stories':

>>             // Call local non-API method to handle Story event

>>             return handleStoryEvent($eventName);

>>         default:

>>         // For all other modules we don't care so bail

>>             return false;

>>     }

>> }

>>

>> Though you can see the trend, here is what you would have in one of 

>> the event handlers.  Let's assume this is the forum's event handler 

>> for messaging:

>>

>> function handleMessagingEvent($eventName)

>> {

>>     switch ($eventName) {

>>         'onPMSent':

>>             return ForumEventHandler::hand

>>     EventHandler::

>> }

>>

>> In this way you don't need to register events in a database.  You may 

>> be able to condense this a bit by using is_callable() or 

>> method_exists() to avoid too many levels of event handling proxies but 

>> this demonstrates my idea.  Again, I think we should trim GL2 down to 

>> essential DB calls and if we can avoid them here I'd like to.  I'm 

>> sure there may be arguments for doing it in the DB which is fine, just 

>> let me know what they are (i.e. I'm not married to any decision yet).

>>

>> Thoughts or concerns?

>>

>> --Tony

>>

>> Vincent Furia wrote:

>>

>>> A couple comments I wanted to add about plugins and other GL2 stuff.  

>>> First, I think that we should consider making some of the 'core' 

>>> functionality into plugins instead. Specifically I'm referring to the 

>>> comment engine, the (potential) ratings engine, and the messaging 

>>> system (maybe even the logging system?).  This would allow users to 

>>> replace the functionality provided by these plugins.  A good example 

>>> of this might be replacing a standard comment system with a 

>>> forum-like comment system.  I think doing so would give GL2 even more 

>>> flexibility.

>>>

>>> I know Tony didn't mean the core feautre list to be exhaustive, but 

>>> one item I didn't see (but would like to see) was a configuration 

>>> utility.  I think, with GL2, we should get away from forcing GL 

>>> administrators from editing config.php by hand and move to a fully 

>>> web based configuration utility that can be used by the plugins as 

>>> well being used for core feautres.

>>>

>>> On that subject I think it's time to start putting together a 

>>> document that shows what core functionality GL2 will provide and any 

>>> information we have on how it will provide that.  Something like a 

>>> design document.  It's something that I'd be willing to work on, but 

>>> I'd need a lot of information and support, especially from Tony.  

>>> Maybe this is something that would best be done in a Wiki format?

>>>

>>> Finally, I have a few comments about event handling system and a few 

>>> comments on plugins in general.  If we do this well, and efficiently, 

>>> we could have a really flexible, extensible system that will beat out 

>>> every other open source system I've seen.  For that reason I think 

>>> its important to focus, briefly on how the plugin event calls might 

>>> work in GL2.  This is just a rough idea, and I'd really like to see 

>>> input on what you all think of this.

>>>

>>> Each plugin should be able to register the fact it wants to be called 

>>> when certain events occur:

>>>    registerEventCallback(plugin registering callback, plugin raising 

>>> event, event)

>>>

>>> Then, a plugin can notify GL2 that event has occurred with:

>>>    raiseEvent(plugin raising event, event, parameters)   // 

>>> parameters: array of values

>>>

>>> Upon being notified that an event occurred, GL2 can call the plugin 

>>> API for all plugins registered to recieve the event:

>>>    onEvent(plugin raising event, event, parameters)

>>>

>>> Also plugins need to be able to invoke an event/function in another 

>>> plugin:

>>>    invokeEvent(plugin providing function, event, parameters)

>>>

>>> I'm still thinking about possible ways raiseEvent and invokeEvent can 

>>> handle returned values. One possibility, at least for invokeEvent, is 

>>> the functions could be required to return a small object containing 

>>> status (-1, failure; 0, plugin function not found; 1, success; etc.) 

>>> and the results of the call:

>>>    $P = invokeEvent(plugin, event, parameters);

>>>     if ($P->status > 0) {

>>>         echo $P->result;

>>>     }

>>>

>>> Of course all this leads to a question if we should have a severely 

>>> simplified API where even core functionality such as the moderation 

>>> fuctions, comment functions, etc should all be called through this 

>>> event API (with a plugin name = 'core').  One advantage to doing it 

>>> this way would allow us to extend plugin functionality in later 

>>> releases without affecting the plugin API (which would prevent plugin 

>>> obsolesence to an extent).

>>>

>>> Another issue I think we should start talking about is plugin 

>>> dependency, and how to handle it gracefully.  Obviously plugins will 

>>> support, to one extent or another, the use of other plugins.  This 

>>> could run the gambit from a plugin being dependent on another plugin 

>>> to work, to a plugin using another plugin in a non dependent way 

>>> (i.e. the plugin isn't required for operation, just for extended 

>>> functionality).

>>>

>>> I think that is more than enough to digest in one sitting.  If anyone 

>>> would like to chat with me I'll try to be available in #geeklog.  Of 

>>> couse, email discourse is always welcome as well.

>>>

>>> -Vinny

>>> Who is already having fun...

>>>

>>> _______________________________________________

>>> geeklog-devel mailing list

>>> geeklog-devel at lists.geeklog.net

>>> http://lists.geeklog.net/listinfo/geeklog-devel

>>

>>

>>

> 

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel


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

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

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