[geeklog-devel] Quick overview of GL2 and what we have so far and how it relates to the API
Vincent Furia
vmf at abtech.org
Fri Oct 31 14:43:34 EST 2003
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...
More information about the geeklog-devel
mailing list