Re: [Phpwiki-talk] RFC: EmailNotification Coding Strategy

[Joe E. <jo...@or...>]

First of all, thanks for your fast & deep& encouraging response.  Here are
some preliminary notes.

"Jeff Dairiki" <da...@da...> wrote:

> Plugins might want to have their own data storage.
> (e.g. FileUploads & weblog plugins.)

Still thinking.  Looks like it won't be necessary for this plugin because
I'm going to accept your alarm/timer proposal.  But I agree-- we need a
general mechanism for plugins to add their own code into the WikiDB
monolith.  Perhaps plugins should be able to register new backend functions
to multiple DB backends from within their one plugin file.  Page metadata
will be able to handle much of this too, but there's no way to SELECT on
page metadata efficiently, right now.  Still thinking.


> In some of these cases it might be nice if the data were stored
> right in the page text, a la what I proposed in my last reply:

I think it's a great idea generally, but not for this application.  I would
prefer a syntax that left the inside data clean-looking:

    <?plugin-begin NotMyPlugin?>
    Slurped data
    <?plugin-end?>

But again, I don't think this is a good approach for NotifyAboutChanges,
because it moves away from PlainEnglish.  I'll go into it more later.


> I managed to
> work around needing global meta-data.  It may well be worthwhile to add.
> A way to hack around it may be to attach the global meta-data to a
> "special" page name (like '' (the empty string)).

It's a hack, but that's okay for my first cut at this.  If you want me to
add wiki-wide data to WikiDB, I'll be happy to do that too.


>   New (and deleted) link detection:
>    Whenever the page is modified, get a list of links before the
>    modification, and compare it to the list of links after modification.
>    This is simple and I think should work fine.

This is what I was going to do anyway.


>   Stale link detection:
>    Whenever a link for which stale link detection has been requested
>    is added to a page, register an alarm (but only if no alarm already
>    exists for that link/page combination) with the timer manager (see
> below).
>    When a link is deleted from a page, check for and delete any pending
>    alarms which are keyed to that link.
>    This is not quite so simple, but should work fine.

Still thinking about it.


> My first guess would be to register an "onNewPageRevision" (or similar)
handler
> which checks for new links and calls the 'onNewLink' handlers
appropriately.

That's fine.  Good suggestion.


> Scheduling actions: Page expire_date's:
>
>  As a more general mechanism, I'd suggest the implementation of alarms
>  (or, more generally still, timers).
>
>  class WikiTimerManager

Excellent!  Okay, I'll do that.  Your API looks good to me.


> A fine idea.  However, I'm not sure WikiEventHandler is necessary

It's not.  I'll leave it out.


>  class WikiEventManager
>  Constructor:  **singleton**
>  Methods:
>      $em->register( $eventName, $callback [, $extra_data] );
>      $em->trigger( $eventName, $args );

Okay.  But I'm going to do an unregister function too, so that hacks like
this work:

    $em->register( 'onWikiLinkDetectedInTransform', 'add_to_links_array',
$pagename );
    do_transform( $pagetext );
    $em->clear( 'onWikiLinkDetectedInTransform', 'add_to_links_array' );


> Perhaps there is a way to combine WikiEventManager and WikiTimerManager?
> Maybe not though... WikiTimerManager manages a persistent queue,
> WikiEventManager does not (at least, I don't think so).

Yes, I think it's best to leave them separate.  WEM should be real simple,
and WTM might get pretty sophisticated.

    Joe