[geeklog-devel] GSoC: Core Notification

Fri Apr 2 18:03:13 EDT 2010

Hello Vincent,

I'm interested in the "Core Notification Support" GSoC project. I've been
hanging on the geeklog IRC channel and playing with the CMS itself for some
time now.
I have lots of experience in OOP in PHP, Python, C++, C, Java, blah blah
blah, won the Google Highly Open Participation Contest (
http://code.google.com/opensource/ghop/2007-8/grandprize.html under
SilverStripe), and did lots of projects that I will include in my formal
gsoc personal summary ;-)

I took a brief look at the Konstantin's draft from 2008(?)
http://docs.google.com/View?docid=dd4t2984_0cf3526cd
I don't know if I should just submit a draft via the gsoc app before sending
a final proposal or write an e-mail so I decided to let you know about my
ideas via e-mail:

*1. The event triggering system*
It will be working like:
*$Event->trigger('eventName', $args)      (another way would be
$Event->eventName($args) , shorter and nicer but harder to understand for
the developer ;-) )*
where $args obviously contain additional info

I don't think event types should be limited to a pre-defined list, I have a
cute idea about registering the event types in a dynamic way
(*$Event->trigger('eventName',
$args) *first checks if eventName is already registered, if not - it
registers the event on a list first (we need the list to let the users
define their subscriptions and manage the events). This way, there would be
no need to define the events in any other place.

Namespaces and wildcards could be easily implemented as well with a proper
naming convention. What I can't see, is the need to use multiple listeners
as described in Konstantin's GDoc - one event processor would work better in
my opinion with eventName patterns as arguments, am I missing something?

*2. Notification Manager*
Because of possible performance issues, the best way to implement the
notification manager would be pushing the triggered events into a queue, and
have a separate notification manager process the successive events.  The
frequency could be easily adjusted to let the site owners choose between
performance, speed and system resource use.
When the notification manager processes the queue, it just checks it against
a separate subscriptions list (subscribers caching would significantly
increase performance), another queue could be created for e-mail
notifications.

*3. Sending Notifications*
There is no need to limit the notifications to e-mail. I could write a
universal solution to support as many notification types as needed (adding a
new type would be just adding a proper method to the notification manager,
nothing hard to code). I was thinking about e-mail notifications (instant /
digest), RSS feeds, IM and SMS messages, maybe Twitter messages?

These are just a few thoughts, nothing final. Please let me know what you
think about the first two points. A potential drawback of the dynamic event
registering would be the de-centralisation of the event specifics.

Best Regards,
Wojtek Szkutnik
Jagiellonian University, Krakow, Poland
http://wojtekszkutnik.com

On Fri, Apr 2, 2010 at 10:22 PM, Vincent Furia <vfuria at gmail.com> wrote:

> I'm going to summarize what we're looking for in the "Core Notification
> Support" GSoC project. I think the wiki page is leading people to the wrong
> idea about what we're looking for in this project. I'll try to update the
> wiki page to make it more clear this weekend.
>
> For a specific example of what we're looking for, check out the the forum
> on geeklog.net <http://www.geeklog.net/forum>. From there you can
> subscribe to an entire Forum or a specific topic. Once subscribed, you can
> remove your subscriptions from a central area that is well organized. You
> also have the ability to configure how frequently you receive notifications
> in the Forum's user settings.
>
> What we want to see with the "Core Notification Support" project is that
> idea generalized to support the entire site, including plugins. In this
> manner you can register to be informed whenever a new story is posted (or
> one in a specific topic), you can subscribe to a story and get notification
> if its updated or comments are added, etc. Once you have created these
> subscriptions you should be able to modify them in one location. You should
> be able to adjust how you receive the notification (daily, per event, or
> once until you visit the site again).
>
> This implies some subdivisions of this project:
>
> 1. Notification Subscription. A user needs to be able to subscribe to
> certain events (e.g. new comment, new story, update, etc). An API needs to
> be created to support this.
>
> 2. Notification Indication. When an event occurs (e.g. a new story posting,
> a new comment left, an error occurs, etc), the thing generating the event
> needs an API to let the Core Notifier [1] know that the event occurred.
>
> 3. Event Handling. The Core Notifier, once it get an indication an event
> occurred, needs to figure out a who needs to be notified and how they want
> to be notified (e.g. when a story is created, it should send an immediate
> email to those subscribed to "all stories" and to the topic it belongs to).
>
> 4. Sending Notifications. At a minimum this is sending email notifications
> [2]. It'd be nice to see a pluggable architecture that allowed additional or
> alternative notification methods to exist. Some ideas are SMS notifications,
> notifications in an RSS feed, on-line notifications (similar to facebook
> notifications while on the site), etc.
>
> I hope this clarifies the requirements on the wiki page. Again I'll try to
> update that this weekend. If you have questions, please let me know. For
> those who already submitted proposals, I'm working on reviews.
>
> -Vinny
>
>
> [1] Core Notifier is a horrible name, please feel free to come up with
> something better. :)
> [2] A nice to haves for email notifications is a site wide speed-limit for
> sending emails. Many Hosts limit the number of emails sent per hour.
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20100403/c343a527/attachment.html>