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

[Blaine Lang]

Vincent,

I've just been reading up on the PostNuke API as I have a module that I need
to develop for a client. This is not Nuke but a totally separate development
effort (for those that are not aware). A lot of what you raise was raising
the same ideas for me as I was reading their module developer and API
documents.

http://noc.postnuke.com/docman/view.php/5/10/pnAPI.htm

Their API is still in development but already has some of the ideas you
presented.
There are a lot of other API's here that we use COM functions or Globals
for. In GL2, we will not be relying on globals so there will be a need for
some of these API or functions to be exposed.

I expect GL2 will be if not 100% OO - very close and I believe PostNuke (
next step for me is to look at their code) is all OO. So this API reference
may be helpfull.
http://noc.postnuke.com/docman/view.php/5/10/pnAPI.html#id2758765

Blaine

----- Original Message -----
From: "Vincent Furia" <vmf at abtech.org>
To: <geeklog-devel at lists.geeklog.net>
Sent: Friday, October 31, 2003 2:43 PM
Subject: Re: [geeklog-devel] Quick overview of GL2 and what we have so far
and how it relates to the API


> 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