[geeklog-devel] GSoC 2008: Core notification service

[Tony Bibbs]

GL2 loads which plugins listen to which events into RAM so I'd say code the thing knowing you'll use caching of some some sort (APC, memcached, etc).

To help fill in some details, each plugin should be able to arbitrarily define any number of events it fires.  Each event should be define so it is clear what the event is, when it gets fired and what parameters are sent with the call.

After that it's a class case of implementing the observer/observerable pattern which, I would expect, would results in additions to the plugin API for doing those sorts of tasks.

I have to disagree with this statement:
"Properly written this code could replace all callable plugin interfaces."

If that was the case there would be no notion of an interface in the OO sense.  The plugin API needs to force the methods a plugin *has* to implement, event handling allow arbitrary communication between two or more losely coupled bits of code.  Sure you *could* do what you are saying but I think it would be in poor design.

--Tony

----- Original Message ----
From: Joe Mucchiello <joe at ThrowingDice.com>
To: Geeklog Development <geeklog-devel at lists.geeklog.net>
Sent: Tuesday, March 18, 2008 4:01:08 PM
Subject: Re: [geeklog-devel] GSoC 2008: Core notification service

Does this code have to run with every page hit?

  //Get instance of the globals
  $dispatcher = Dispatcher::getInstance();
  //Add pluginname_eventobserver function as listener for myEvent
  $dispatcher->addObserver('myEvent', 'pluginname_eventobserver');

Telling the system every event I'm interested in with each run seems 
strange especially when the page being loaded might never interact 
with subsystems I'm looking to observe. I assume this code only has 
to run in the existing plugin_install (and be handled in 
plugin_enablestatechange). Once called, the database maintains a 
relationship of events to handler functions and when an event fires, 
the functions are called one at a time.

Since there are no database layouts/mockups in the proposal so I have 
no way of knowing your plan.

I think 2 weeks to retrofit into GL Core is optimistic. Properly 
written this code could replace all callable plugin interfaces.

Finally, I recommend doing the UI part as a plugin since the plugin 
API is not a moving target like the codebase can be. Later 
integration should be easier than if you've randomly edited the core.

   Joe

At 11:27 AM 3/18/2008, Konstantin Mikhaylov wrote:
>Hello guys.
>
>I congratulate you with acceptance in GSoC 2008.
>
>Can i recieve some feedback on my proposal?
>It is located http://docs.google.com/View?docid=dd4t2984_0cf3526cd
>
>Any thoughts and suggestions are very appreciated.
>Sorry for my bad english
>
>--
>Thanks, Konstantin
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://eight.pairlist.net/mailman/listinfo/geeklog-devel

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 

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