[geeklog-devtalk] geeklog-devel digest, Vol 1 #218 - 4 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Quick overview of GL2 and what we have so far
       and how it relates to the API (Vincent Furia)
   2. Re: Quick overview of GL2 and what we have so far
       and how it relates to the API (Tony Bibbs)

--__--__--

Message: 1
Date: Sun, 02 Nov 2003 21:03:15 -0500
From: Vincent Furia <vmf at abtech.org>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Quick overview of GL2 and what we have so far
 and how it relates to the API
Reply-To: geeklog-devel at lists.geeklog.net

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

>

>




--__--__--

Message: 2
Date: Mon, 03 Nov 2003 09:45:44 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Quick overview of GL2 and what we have so far
 and how it relates to the API
Reply-To: geeklog-devel at lists.geeklog.net

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                  |

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



--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest