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