[MojoMojo] Ideas about notification

Rob Hoelz rob at hoelzro.net
Wed Nov 25 20:16:13 GMT 2009

Am Nov 25, 2009 um 12:12 schrieb Marcus Ramberg <marcus at nordaaker.com>:

> On Wed, Nov 25, 2009 at 1:33 PM, hoelzro <rob at hoelzro.net> wrote:
>> Hello, MojoMojo!
>> I'm an ambitious young developer who's been using MojoMojo for  
>> quite some
>> time now, and I figured that I should put my Perl and Catalyst  
>> skills to
>> good use outside the workplace and contribute to a project as great  
>> as
>> MojoMojo.
> That's excellent news for us :-)
>> Now that my introduction is out of the way, onto my ideas about
>> notification.  I was looking at the issue pertaining to notification
>> (http://github.com/marcusramberg/mojomojo/issues#issue/49), and I  
>> like the
>> "More Difficult" option, where anyone can subscribe to a page's  
>> changes.  I
>> have some ideas on how to expand upon that:
>> - How about a recursive watch, so a user can monitor all page  
>> changes under
>> a certain namespace?  This would allow admins to monitor the whole MM
>> instance without much hassle.
> How would this differ from an RSS feed of recent page edits?

Well, the only real use of the feature would be for people who want to  
receive e-mail instead of using RSS, and also for only monitoring  
subtrees (ie. /development).
>> - I think a checkbox on page creation/edit to subscribe to that  
>> page's
>> changes would be cool.
> I like this idea, even though I worry about clutter on the editing
> interface. Not sure how we make such things scale well.

Since editing the template is so simple, we could always play around  
with this until we find an acceptable solution or scrap the idea  
altogether.  As far as scaling of UI elements goes, we could offer  
some sort of 'Advanced Settings' dropdown, perhaps.
>> - A user setting to automatically subscribe to pages that that user  
>> creates
>> or edits would also be nice.
> This might be a better approach to the problem
>> - Some sort of subscription management UI in the user's profile/ 
>> preferences
>> page would be nice.
> Agree
>> - As far as the actual implementation of the notification system  
>> goes, I
>> propose a generic notification mechanism that various output  
>> modules could
>> subscribe to.  A page (or something else in the future) would  
>> publish a
>> changed event, and any installed output modules would broadcast the  
>> contents
>> of the message to all interested parties.  That way, we could  
>> implement
>> output modules for e-mail, XMPP, or anything else that comes to  
>> mind in the
>> future.  When users subscribe, they can specify how they want to  
>> receive
>> notifications.
> Might not want to overengineer this. Let's try to start reasonably
> simple with a DBIC class for notifications

Alright; starting simple never hurts.
>> Granted, several of these ideas would take a lot of work, and some  
>> may be
>> difficult to implement efficiently.  Please let me know what you  
>> think of
>> them.
> In general I think starting simple and then seeing from experience
> what more we need is a better approach than implementing something
> complicated out of the box.
> With regards
> Marcus Ramberg
> _______________________________________________
> Mojomojo mailing list
> Mojomojo at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/mojomojo


More information about the Mojomojo mailing list