[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