phpwiki-talk

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

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

> Yes, this is problem.  I've got vague notions of adding an API to WikiDB
> to allow the addition of arbitrary "indexes" or something.

Yes.  Something like that.  I feel like we're reinventing SQL...  I guess
that's the right thing to do!


> Adding a (perhaps optional) $key argument to $em->register would
> probably be a good idea.

Okay.


>  (Or perhaps better, though it's yet another different
> API, have $em->register return a key or handle while can be used to
unregister the
> callback.)

Well that's why I had the WikiEventHandler class before, so you could say:

    $eh = new WikiEventHandler ( $event, $function );

and

    $eh->destroy();


> And, in case I didn't mention it before, it's probably time to implement
> WikiCallback as a bona fide class.

Sure.  Makes sense.


    Joe

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

[Jeff D. <da...@da...>]

On Wed, 21 Nov 2001 11:11:03 -0500
"Joe Edelman" <jo...@or...> wrote:

> 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.

Yes, this is problem.  I've got vague notions of adding an API to WikiDB
to allow the addition of arbitrary "indexes" or something.
(Think about want to add new and experimental page "score" algorithms.)
It would be nice to abstract the process away from the SQL model.
I haven't come up with a clean way to do this yet.

> 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' );


The main reason I proposed the $key argument to
WikiTimerManager::registerTimer,
is to provide for clean identification of handlers when one wants to
unregister
it.  Adding a (perhaps optional) $key argument to $em->register would
probably
be a good idea.  (Or perhaps better, though it's yet another different
API, have
$em->register return a key or handle while can be used to unregister the
callback.)


And, in case I didn't mention it before, it's probably time to implement 
WikiCallback as a bona fide class.  There are already a number of places
where callbacks are passed around.

 class WikiCallback
 Constructor: new WikiCallback($globalFunctionName)
              new WikiCallback($object, $methodName)
 Methods:
      $cb->call([$args [,...]]);
      $cb->call_array($arrayOfArgs);

      $cb->getPearCb();
          Returns Pear style callback: either a string for a global func,
            or an array of length two for an object method callback.

In fact, if I find time this morning, I'll try to code it up.

Jeff
PS.  I'll be gone for Thanksgiving, so if I'm silent, that's why.

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

Re: [Phpwiki-talk] RFC: EmailNotification Syntax and Features

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

"Adam Shand" <ad...@pe...> wrote:

> i would vote to remove the email option, it makes it too easy for anyone
> to sign up anyone to get spammed on change notification.

How about this:  For release 1 (november) bare emails are possible but by
default turned off;  For release 2 (january) I'll support some kind of email
confirmation scheme.


> having all
> notifications routed to a wiki page (and thus to an email) also provides a
> single point of maintenance for end users

Right, the wiki page approach is clearly the better way to add yourself to a
list, but I expect that a lot of my users will start as lurkers over email,
so I want to make lurking as easy as possible:  just an edit away.  They can
always fix it later, when they become contributing members with their own
pages.  Certainly it should be off by default, though:  I don't want these
wikis to become known spam relays!


> it would be nice if the notion of groups could be generalized so it could
> be leveraged for authentication purposes.  i can't comment if this meets
> that criteria or not.

Yes.  Neither can I.  I promise that there will be an easy-to-use method for
accessing all the members of this kind of group, and I promise that whatever
auth solution is arrived at, I'll try to make this blend in.

Re: [Phpwiki-talk] RFC: EmailNotification Syntax and Features

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

"Steve Wainstead" <sw...@pa...> wrote:

> would it be possible to code for this scenario:
>
> PamOne adds her name to NotifyAboutChanges.
> Email is sent to PamOne to confirm.
> If she confirms, OK; if not, no further mail is sent for that page, and
>   possibly her name is removed from the page's list.

Yes.  I'll implement this.  I want this functionality too.  But this will be
in my second revision, probably during January.


> Also, users would need a form page telling them what they are subscribed
> to and let them unsubscribe from any page (or all of them).

Good idea.  FullTextSearch might work until I can rig a more user-friendly
plugin version.


> What I find enlightening about Joe's approach is sticking with Wiki markup
> to do the job, in plain English (or pick your native language ;-) It's
> incredibly simple and Wiki-like.

Yeah, I tried to refactor myself after you folks schooled me on WikiBadges
and WikiNature.  StructuredDataNoMore!


Thanks everyone for your positive feedback.  Feel free to continue to
suggest changes and ideas as they come to you.  More to come.

    Joe

Re: [Phpwiki-talk] RFC: MAILBOX format: HEADER - BODY

[Adam S. <ad...@pe...>]

> So we could have standard headers (formerly called meta-data)  plus
> header plugins for the owner, plus body plugins for the users:

i like the idea of page meta data being stored in the page *very* much.
however i'm not so keen on actualy using mbox format for it.  unless it's
much easier to parse because of mime modules for php (or similar reason) i
would like to see a more human readable syntax.  something like:

#Owner: AdamShand
#Group: SomeGroup
#HeaderPermissions: -rwxr-x---
#BodyPermissions: -rwxrwxr-x

and then the page SomeGroup could have:

#Owner: SteveWainstead
#GroupMembers: SteveWainstead Jeff Dairiki AdamShand
#HeaderPermissions: -rwx------
#BodyPermissions: -rwxr-xr-x

etc etc.

> Haven't got an idea yet how to define group ownership in the header.
> Similar to a stupid unix-filesystem or an ACL list?

i think unix file system permissions are sufficient and they are fairly
well groked by the public.

> To parse out a header from the pagename is not slower than a seperate
> db access for the meta-data, and it is easier for the fs version.

it's also wiki'ish in the sense that the wiki page actually contains all
the information about itself, in itself.

adam.

ps. i just re-read this and i'm not sure i've done anything useful.  i
think i just removed what was novel about reini's approach and obfuscated
joe's ... but for what it's worth ... here it is anyway.

[Phpwiki-talk] RFC: MAILBOX format: HEADER - BODY

[Reini U. <ru...@x-...>]

> > 3. WHERE SHOULD I PUT MY DATA?

another wiki-like crakpot idea:

WHY NOT DO IT SIMILAR TO A UNIX-MAILBOX FORMAT?

A single page, a header with all metadata, editable by the owner and the
system, 
and the body which is viewable, editable by all. 
(dependent on some header info, like permissions (for locks, plugin execution,
...), 
header plugins like notifiers, timers, ...)

So we could have standard headers (formerly called meta-data) 
plus header plugins for the owner, plus body plugins for the users:

<begin samplepage>
>From WikiOwner Sun Jul 1 03:47:45 2001
Subject: WikiPage
Message-ID: <23...@ph...>
From: Wik...@ph...
Date: Sun, 1 Jul 2001 03:47:45 +0200
Mime-Version: 1.0 (Produced by PhpWiki 1.3.x)
Content-Transfer-Encoding: iso8859-1
Content-Type: application/x-phpwiki
Keywords: php wiki mailboxformat
X-Revision: 1.14
X-Created:  2001-08-01 13:00:00
X-Group: root
X-HeaderPermissions: -rwxr-xr-x
X-BodyPermissions:   -rwxrwxrwx
X-Plugin-NotifyAboutChanges: WikiOwner
X-Plugin-PageAlias: OtherPageName
X-Plugin-MaxSize:   2000
X-Plugin-WikiTimer: action="SetHeader"; 
		    value="BodyPermissions: -rwxr-xr-x";
                    when="2001-12-27 22:00:01"
X-Plugin-BodyTransformPCRE: trigger="/regex/ig"; to="/$1 regex/";
when="before"
X-Plugin-BodyTransformPCRE: trigger="/<code>(.*)</code>/"; to="/$1/"; 
	transform="wtm_code"; mode="WT_MODE_MARKUP"; when="before"
X-Plugin-BodyRegisterToken: token='RELATEDPAGES'; eval='<?php echo "blabla" .
LinkRelatedPages($dbi, $name) ?>'

This a WikiPage in a unix mailbox format (header-body)
<?plugin NotifyAboutChanges --
         JoeEdelman ?>
<?plugin BodyTransformPCRE trigger="/WikiPage/g"; to="/Sample $1/";
when="before" ?>

See ###MYRELATEDPAGES###
<eof samplepage>

The X-Plugin-WikiTimer is the WikiTimer plugin which performs 
<?plugin SetHeader BodyPermissions: -rwxr-xr-x ?> at a certain time.
(recurring or once)
Via the standard `at` scheduler probably. this works on unix and windows at
least.
so we would have a good time syntax available. platform dependent of course,
but cute.

Permissions:
Any user may edit the whole page with headers via action="adminedit",
defined by X-HeaderPermissions w for u (owner), g (group) or o (other).
Similar to X-BodyPermissions which implements locks for groups and world.

Haven't got an idea yet how to define group ownership in the header.
Similar to a stupid unix-filesystem or an ACL list?

Is this good enough to add it to the phpwiki page?
I also like jeff's idea of a global '' page for global meta-data. 
very wiki-like.

To parse out a header from the pagename is not slower than a 
seperate db access for the meta-data, and it is easier for the 
fs version.

See http://www.landfield.com/rfcs/rfc2822.html for the reference.

jeff already did it for the zipdump. just the quoted-printable mime-type is
questionable.
I would strongly prefer 8-bit Latin-1, since we don't have to transport that
over SMTP.
the zipdumps could then be the standard format, which would make backups much
easier 
to handle.

For now it looks like:

>From ro...@xa...  Mon Jul 2 09:50:50 2001
Subject: OrphanedPages
From: ro...@xa... (PhpWiki)
Date: Sun, 1 Jul 2001 03:47:45 +0200
Mime-Version: 1.0 (Produced by PhpWiki 1.3.0pre5)
Content-Type: application/x-phpwiki;
  pagename=OrphanedPages;
  author=PhpWiki%20-%20dynamic;
  version=0;
  flags=PAGE_LOCKED;
  lastmodified=993952065;
  created=993952065
Content-Transfer-Encoding: quoted-printable

Jeff Dairiki schrieb:
> You bring up several issues, most of which are inter-related.
> Here's some ramblings on those and related subjects.
> 
> > 3. WHERE SHOULD I PUT MY DATA?
> 
> This is certainly one of the bigger unresolved issues in PhpWiki
> development that I see today.  I'm not real happy with any of the
> proposed solutions (either yours or mine) yet.  (What follows is
> mostly more questions, not many answers...)
> 
> There is all kinds of data we might like to store which currently
> doesn't fit into the WikiDB.
> 
> Plugins might want to have their own data storage.
> (e.g. FileUploads & weblog plugins.)
> 
> 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:
>   <?plugin NotifyAboutChanges --
>            JoeEdelman ?>
> where everything after the '--' is 'meta-data'.  What if there
> were any API by which the plugin could modify that data itself?
> Then the "notify me when this page is edited" button could become
> reality.  (Eh.. maybe it's a crackpot idea.)
> 
> In other cases, the plugin might like meta-data which can't be
> edited by the user, so the data would need to be stored some other way.
> (Page meta-data in WikiDB may be handle much of this?)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] secure-phpwiki (fwd)

[Steve W. <sw...@pa...>]

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
---------- Forwarded message ----------
Date: Tue, 20 Nov 2001 17:52:56 -0200 (BRST)
From: Antonio Terceiro <ter...@im...>
To: wai...@us...
Subject: secure-phpwiki

Hi,

  I've developed a more secure implementation of PhpWiki, based on the original
PhpWiki at all. I called it secure-PhpWiki, and it can be found at
http://www.im.ufba.br/~terceiro/secure-phpwiki.tar.gz . Please announce it to
the others PhpWiki developers.

  I've been used it at http://wiki.im.ufba.br , and at
http//www.im.ufba.br/~terceiro/phpwiki .

Regards,

Antonio Terceiro
ter...@im...

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

[Jeff D. <da...@da...>]

You bring up several issues, most of which are inter-related.
Here's some ramblings on those and related subjects.

> 3. WHERE SHOULD I PUT MY DATA?

This is certainly one of the bigger unresolved issues in PhpWiki 
development that I see today.  I'm not real happy with any of the
proposed solutions (either yours or mine) yet.  (What follows is
mostly more questions, not many answers...)

There is all kinds of data we might like to store which currently
doesn't fit into the WikiDB.

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

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:
  <?plugin NotifyAboutChanges --
           JoeEdelman ?>
where everything after the '--' is 'meta-data'.  What if there
were any API by which the plugin could modify that data itself?
Then the "notify me when this page is edited" button could become
reality.  (Eh.. maybe it's a crackpot idea.)

In other cases, the plugin might like meta-data which can't be
edited by the user, so the data would need to be stored some other way.
(Page meta-data in WikiDB may be handle much of this?)

The file upload case is taxing in that image files, etc.. are big.
We probably don't want them in the (e.g. SQL) database, but rather
as flat files somewhere.

 (One slick syntax for handling file uploads which just occured to me
  might be:

  <?plugin Inclusion type="image/gif" ?>

  After such a plugin invocation is added to a page, the marked-up page
  will show a file upload form where the plugin is.  After a file is
  uploaded, the uploaded file is shown instead.  If the plugin invocation
  is deleted, then the uploaded file (if any) is deleted as well.
  (Of course, I'm still not sure how this all would be implemented.))


> Existing plugins use code in WikiDB and in the backends to talk with the
> database.  This is very portable but not so modular-- even folks who
never
> use the plugin have to wait while PHP parses the DB code for it on page
> loads.  It seems to make sense to leave WikiDB as is and put mysql-only
code
> directly into the plugin file.  Is that right?

I don't think I understand your objections.  I don't really see very many
situations where you could do anything useful without the DB code (if you
want any page text, or page meta-data it has to come from the DB).

Also, I would think that mysql-only code is to be avoided.  One of my
peeves
with 1.2.x is that the featureset is different for each back end.  (Page
scoring
only works with some backends, the syntax for title/full-text searches
varies
among the different backends, etc...) I guess, to some degree, that is
unavoidable,
but I would prefer to see the features coded as portably as possible.
(Suppose a plugin is written to only work with mysql, then someone comes
along
and want to make with work with dba data store.  Does he need to create a
whole
new plugin?)



> Also, is there any preference as to how I store wiki-wide dynamic data?
> Should I make a "wiki" table with one row and (for now) one column?  Is
this
> something specific to my application or something that people would a
> general (WikiDB) interface to?

I almost included an API in WikiDB to do just that.  Then 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)).  

===================
> 1.1  EVENT-BASED PLUGINS
 
>     include('lib/plugin/NotifyAboutLinks.php');
>     include('lib/plugin/NotifyAboutChanges.php');

My proposed <?plugin NotifyAboutChanges -- ... ?> syntax would eliminate
the need for these particular explicit include()s.  In general though,
the idea of solely event-based plugins is probably a useful one.
===================

Link ctimes & extra link meta-data:

 One alternative which doesn't require the storage of new link meta-data,
and
 thus doesn't require big changes to the database backend is as follows:

  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.

  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.

> The most sophisticated thing to do would be to create a WikiDB_Link
object
> similar to WikiDB_Page and WikiDB_PageRevision and have that object
support
> arbitrary data get() and set() like the others, and do the same kind of
> translation between a $data[] array and the database fields.

If you really feel the need to add ctime meta-data to the links, I think
this is the way to go.

> This involves serious changes to the API for both the various backends
and WikiDB,
> complicates the code, and is something to be very careful about because
> certain functions would be changing their return values from arrays to
> iterators.

Yes. :-)

> With this approach it is still unclear where the best place to trigger
> "onNewLink" events would be.

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

====================

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
 Constructor: **singleton**
 Methods:
    $am->registerAlarm( $key, $timeout, $handler [, $data  ])
          $key     (string) unique identifier for queued alarm.
          $timeout expiry time of alarm
          $handler callback: either global function name (string) 
                   or pair: array($object, 'methodName').
                (Or maybe it's time to implement a WikiCallback class.)
                   Callsbacks should return:
                     TIMER_OK:
                     TIMER_DELETE: Unregister this timer.

          $data    Arbitrary data to be passed to handler
          $type    

    $am->registerTimer( $key, $interval, $handler [, $data])
          Similar to registerAlarm, except registers a recurring
          callback.

    $am->unregister( $key );

    (Probably methods to iterate through the registered timers would
     be needed....)

    $am->run();
          Run any pending alarms.

(Other API's are possible.  My only strong feeling here is that a
TimerManager or some such would make for cleaner code than messing
with page expire_date's (and also be more generally useful for other
scheduling tasks, as well).


===============

> class WikiEventHandler
> Constructor:  new WikiEventHandler( $eventName, $handlingFunction )
> Methods:
>     $eh->destroy();  // unregisters the event handler
>     $eh->getEventName();
>     $eh->trigger( $data[] );
> 
> class WikiEventManager
> Constructor:  **singleton**
> Methods:
>     $em->register( $handler );
>     $em->unregister( $handler );
>     $em->trigger( $eventName );

A fine idea.  However, I'm not sure WikiEventHandler is necessary, what
about just:

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


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).

===============
Okay, enough rambling for now.
Jeff

Re: [Phpwiki-talk] RFC: EmailNotification Syntax and Features

[Steve W. <sw...@pa...>]

On Tue, 20 Nov 2001, Adam Shand wrote:

>
> > RFC: EmailNotification Syntax and Features
>
> this is great, thanks for publishing this.

Yes, most excellent!

>
> >     NotifyAboutChanges:
> >
> >     * JoeEdelman
> >     * TheHumanResourcesDepartment
> >     * ji...@mi...
>
> i would vote to remove the email option, it makes it too easy for anyone
> to sign up anyone to get spammed on change notification.  having all
> notifications routed to a wiki page (and thus to an email) also provides a
> single point of maintenance for end users (need to change your email you
> just have to do it in one place).  if you remove the email meta-data (or
> maybe change it to a keyword like "disabled") it would also provide an
> easy way to temporarily unsubscribe.

Right.. we should bear in mind that people will want to set up a public
Wiki and only registered users can receive email notification.

Also... would it be possible to code for this scenario:

PamOne adds her name to NotifyAboutChanges.
Email is sent to PamOne to confirm.
If she confirms, OK; if not, no further mail is sent for that page, and
  possibly her name is removed from the page's list.

Also, users would need a form page telling them what they are subscribed
to and let them unsubscribe from any page (or all of them).

What I find enlightening about Joe's approach is sticking with Wiki markup
to do the job, in plain English (or pick your native language ;-) It's
incredibly simple and Wiki-like.

Also I think we may need (in the future) unbuffered output from the Wiki
when pages are saved... giving the user feedback as the engine does its
thing. I did this for the editing tools at the New York Times when I
wanted to get a lot of cruft removed from the system, but couldn't get
approval;  by letting the editors see what the tool was doing, they were
able to complain it was doing things that weren't necessary and I got the
approval I needed.

~swain


---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] RFC: EmailNotification Syntax and Features

[Jeff D. <da...@da...>]

On Tue, 20 Nov 2001 13:06:32 -0500
"Joe Edelman" <jo...@or...> wrote:

> RFC: EmailNotification Syntax and Features

This is great!

Here are some of my initial comments.
> THE  SYNTAX
> 
> The following wiki code:
> 
>     NotifyAboutChanges:
> 
>     * JoeEdelman
>     * TheHumanResourcesDepartment
>     * ji...@mi...

I'm just thinking out loud, but what about something like

<?plugin NotifyAboutChanges 
  --
  JoeEdelman 
  TheHumanResourcesDepartment
?>

It's perhaps a little uglier and more complicated for users to suss out.
But it makes it more readily apparent that magic is going on.

The plugin could be made to display a "Notify me when this page is edited"
button, etc...

(Right now, I think, the transform code doesn't support multi-line plugin
forms,
so for now it would all have to be on one line.  That will be fixed at
some
point, though.)

>     NotifyAboutLinks:
> 
>     * TheFinanceDepartmentDweebs

<?plugin NotifyAboutChanges linksonly=true -- TheFinanceDepartmentDweebs
?>

Arguments which limit the links which are of interest would also be
possible.

> 2.
> 
> And in certain cases I want to send notifications whenever a page has
had a
> certain Category or Badge for an amount of time-- for instance when
"FixMe"
> has been on a page for a week and no one has fixed it.  On the "FixMe"
page:
> 
>     NotifyAboutLinks (older than 1 week):
> 
>     * JoeTheFixMeGuy

<?plugin NotifyAboutStaleLinks timeout="1 week" -- JoeTheFixMeGuy ?>
 


I guess I hate to introduce still more new syntax.  (Though I admit I'm
not
really one to cast stones, being that MagicPhpWikiURLs and the plugin
syntax
are both my fault.)

I'm certainly not completely happy with the plugin syntax at this point,
and
you should have no fear of proposing changes to it...

More in the reply to your next post...

Jeff

Re: [Phpwiki-talk] RFC: EmailNotification Syntax and Features

[Adam S. <ad...@pe...>]

> RFC: EmailNotification Syntax and Features

this is great, thanks for publishing this.

>     NotifyAboutChanges:
>
>     * JoeEdelman
>     * TheHumanResourcesDepartment
>     * ji...@mi...

i would vote to remove the email option, it makes it too easy for anyone
to sign up anyone to get spammed on change notification.  having all
notifications routed to a wiki page (and thus to an email) also provides a
single point of maintenance for end users (need to change your email you
just have to do it in one place).  if you remove the email meta-data (or
maybe change it to a keyword like "disabled") it would also provide an
easy way to temporarily unsubscribe.

having a wiki page in order to get email notifications doesn't seem too
onerous.

some form of ack on the addition of an email to a page would be useful to
avoid people signing other people up (you add email meta data and then to
have it activated you have to respond to an email or something similar).

> should do what you expect if the page "TheHumanResourcesDepartment"
> contains somewhere:
>
>     GroupConsistsOf:
>
>     * AlexHamilton
>     * TomJefferson
>     * ge...@ho...

it would be nice if the notion of groups could be generalized so it could
be leveraged for authentication purposes.  i can't comment if this meets
that criteria or not.

adam.

[Phpwiki-talk] RFC: EmailNotification Coding Strategy

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

RFC: EmailNotification Coding Strategy

0   QUESTIONS & ISSUES

I have some questions about how to implement the functionality described in
the other RFC-- "EmailNotification Syntax and Features".  Notably:

(1) I would like to implement all of this using plugins which are only
loaded by those who need the functionality.  This will require an extension
of the plugin concept to allow for "event-based" in addition to
"content-based" plugins, and the placement of hooks inside WikiDB.php to
trigger events.

(2) I would also like to modify the existing code to keep track of the time
that links were created, and I have some questions about how best to do
that.

(3) I would like to ask the various experts here on the list how they think
my plugin can deal with the database in the most portable, modular, and
flexible way.

(4) I will explain a little how the plugins will work internally.


1.1  EVENT-BASED PLUGINS

The event-based plugin functionality is orthogonal to the existing content
plugin functionality, and it could be a completely separate thing.  It seems
like it makes sense to allow plugins to be both at once, though.   Imagine a
plugin for a database-backed tree-hierarchy organization of pages based on
multidimensional scaling or clustering on page text:  the event-side could
do the necessary reindexing every time a page is modified, and the
content-side would allow people to view the index using the "<?plugin?>"
syntax.

The principal thing that an event-based plugin needs to do is register one
or more functions or methods to be triggered at certain times by the
WikiEventManager using a line like:

    new WikiEventHandler ('onMajorRevision',
'function_that_checks_for_notifications');

It can do this registration when it is include()ed, I guess.  Since these
functions won't be loaded by the content-plugin engine unless they're used,
they'll need to be included manually from index.php if they're going to be
turned on.

    include('lib/plugin/NotifyAboutLinks.php');
    include('lib/plugin/NotifyAboutChanges.php');

Much functionality which transcends mere content could be refactored into
event plugins.  Logging, for instance, is event-driven, as is maintanence of
the "recent" table (which could sit together with the existing RecentChanges
plugin code).  All of the wacky indexing schemes that have been proposed
could be done with plugins possessing and event/content dual nature.


1.2  HOOKS INSIDE WikiDB::createRevision

WikiDB::createRevision seems to be the most sensible place to check for
needed notifications, because it stands above the database backends and is
not tied to a particular user action like savepage.php is.  I intend  to add
four lines to this function like:

    if (!$data['is_minor_edit']) {
        global $WikiEventManager;
        $WikiEventManager->triggerEvent('onMajorRevision', $this);
    }

and, depending on how I solve the link.ctime problem below, perhaps also two
lines like:

    foreach ($backend->get_new_links() as $new_link)
        $WikiEventManager->triggerEvent('onNewLink', array( $this,
$new_link ));

Unless handlers for these events have been installed, these calls will be
no-ops.  This will be made possible be two little classes called
WikiEventManager and WikiEventHandler which I'll place in
lib/WikiEventManager.php.


2. TRACKING THE LINK.CTIME

PhpWiki already keeps information about which pages link to which other
pages in the "link" table for use by BackLinks and certain other features.
Currently, when a page is revised, all the old information about what the
page linked to is deleted from the database, the new page data is scanned
for links, and all of these links are added to the database fresh, even
though most of them may have been in the previous revision.  For my
application, I need to know which links are new, and I need to store
information about when each link on a page was added in the database.  I
could do this with a separate table, but that would involve an inelegant &
abnormal replication of the link table and would obscure what should
probably be a central service.

I need to know which links are new so that I can fire off "onNewLink" events
from createRevision (described above).  I need to store the age of links in
the database so that, when notifications are being sent, the script can
notify about just those links that the users haven't been notified about
yet.

The simplest thing to do would be to hack the PearDB::set_links function so
that it registers a ctime for new links, doesn't clobber old links, and
stores a list of the new links in some hidden instance variable; then I
could write a getter function (backend::get_new_links()) for that instance
variable which would only work when called immediately after a set_links
call.  Then WikiDB::createRevision could call that getter and use it to
trigger "onNewLink" events.

The most sophisticated thing to do would be to create a WikiDB_Link object
similar to WikiDB_Page and WikiDB_PageRevision and have that object support
arbitrary data get() and set() like the others, and do the same kind of
translation between a $data[] array and the database fields.  This involves
serious changes to the API for both the various backends and WikiDB,
complicates the code, and is something to be very careful about because
certain functions would be changing their return values from arrays to
iterators.  If the consensus is that this is the only way to do it, however,
I will try and do it myself in Jeff's style.  With this approach it is still
unclear where the best place to trigger "onNewLink" events would be.

I should also note that, for efficiency, link.ctime needs to be indexible in
the database, so there would be a link.ctime added to the database table
(rather than just a serialized "linkdata") anyway.

There are various solutions in between the simple one and the sophisticated
one.  For instance, rather than hack set_links as per the simple approach, I
could expand the backend API to include "add_links" and "remove_links" and
raise the detection of new links up into WikiDB's sphere of influence.

Personally, I don't think it makes sense to do the sophisticated thing now.
If we find out that we need a layer of abstraction around links in the
future, we can always do it then.

But that's just me, what do you think I should do?


3. WHERE SHOULD I PUT MY DATA?

 Aside from link.ctime, which is covered above, the NotifyAboutLinks plugin
needs to track two additional peices of data.

(1)  For each page which has a NotifyAboutLinks (older than X) block on it,
we need to cache that page's "expiration date", which is the earliest date
on which the last notification for the most recent event could be sent out.
This will save us from parsing through the full text of every page in the
database every time we check for notifications.  Since most pages won't have
expiration dates (they will tend to be on Category pages), I think it makes
sense to use a separate table for this.

(2)  For the entire wiki, I would like to store the date on which the last
check for notifications was run, so that we can check for notifications that
have become necessary in between then and now.

Existing plugins use code in WikiDB and in the backends to talk with the
database.  This is very portable but not so modular-- even folks who never
use the plugin have to wait while PHP parses the DB code for it on page
loads.  It seems to make sense to leave WikiDB as is and put mysql-only code
directly into the plugin file.  Is that right?

Also, is there any preference as to how I store wiki-wide dynamic data?
Should I make a "wiki" table with one row and (for now) one column?  Is this
something specific to my application or something that people would a
general (WikiDB) interface to?


4  ABOUT THE PLUGIN

4.1  SQL STATEMENTS

The most important SQL statement, run on every invocation of
admin/notify.php, finds the pages that need to be examined for outgoing
notifications, and looks like this:

    select page_id from page_notify
    where expire_date > [DATE OF LAST NOTIFICATION]

The "expire_date" is a calculated cached (ab-normalized) value that takes
the last time anything was linked to the page ("max(ctime) from link where
to=page_id") and adds the maximum time interval mentioned on the page in an
"(older than X UNITS)" clause.  If the last time we notified people all the
links on the page were too old to get notifications, and there have been no
new links, we don't need to check that page.

The other important SQL statement, run per-page on every page returned by
the first query, identifies, for each "(older than X UNITS)" block on each
page, which new links notifications should be sent out to all the emails
listed in that block.  Any link that has become relevant in between now and
the last notify is included.  It looks like this:

    select "from" from link
    where to=[PAGE_ID]
    and ctime > [DATE OF LAST NOTIFICATION] - ["OLDER THAN" DELAY]
    and ctime < now() - ["OLDER THAN" DELAY"]


4.2  DATA MAINTANENCE

Whenever there is a new link to a page with a NotifyAboutLinks keyword, or
whenever a NotifyAboutLinks time duration is added, removed, or changed, we
need to update that page's expiration_date.


4.3  NEW FILES

admin/notify.php
// functions to do actual notification

lib/WikiEventManager.php
// A simple class for abstracting the hooking mechanism used below

lib/plugin/WikiEmails.php
// Classes for the new syntax & for sending emails

lib/plugin/NotifyAboutLinks.php
// handlers for the feature

lib/plugin/NotifyAboutChanges.php
// handlers for the feature


4.4   CLASSES

A CLASS FOR PARSING THE SYNTAX

class WikiEmailList
Constructor:  new WikiEmailList( $wikiPage, $keywordString );
Methods:
    $w->findOnPage();  // returns 1 if another keyword-headed block is found
    $w->emails();  // returns a list of email address strings from the
current block
    $w->args();  // returns "older than" thingie if it's there in the
current block

class NotifyAboutChangesList extends WikiEmailList
Constructor:  new NotifyAboutChangesList( $wikiPage );

class NotifyAboutLinksList extends WikiEmailList
Constructor:  new NotifyAboutLinksList( $wikiPage );
Methods:
    $n->delay();  // returns the "older than" delay for this block in
seconds


A CLASS FOR THE OUTGOING EMAILS

class WikiEmail
Constructor:  new WikiEmail( $msg );
Methods:
    $e->sendToBlindly( $addresses[] );

class NotifyAboutChangesEmail extends WikiEmail
Constructor:  new NotifyAboutChangesEmail( $wikiPage );

class NotifyAboutLinksEmail extends WikiEmail
Constructor:  new NotifyAboutLinksEmail( $fromPages[] );


A CLASS FOR DISPATCHING ON EVENTS

class WikiEventHandler
Constructor:  new WikiEventHandler( $eventName, $handlingFunction )
Methods:
    $eh->destroy();  // unregisters the event handler
    $eh->getEventName();
    $eh->trigger( $data[] );

class WikiEventManager
Constructor:  **singleton**
Methods:
    $em->register( $handler );
    $em->unregister( $handler );
    $em->trigger( $eventName );

[Phpwiki-talk] RFC: EmailNotification Syntax and Features

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

RFC: EmailNotification Syntax and Features

This is an email notification scheme I designed to cover my needs in my own
projects.  It may be that it is not appropriate to most people's uses or
tastes.  I'm posting the description here to gauge support and to solicit
improvements from people who require slightly different functionality.
Implementation details and questions are covered in another RFC called
"EmailNotification Coding Strategy".

SUMMARY

 - PlainEnglish email list syntax
 - notification about badge status as well as page changes
 - optional anti-spam measures
 - phpwiki/admin/notify.php can be run as a cron job to send emails
 - hopefully implemented & tested by Dec 1st.


THE  SYNTAX

The following wiki code:

    NotifyAboutChanges:

    * JoeEdelman
    * TheHumanResourcesDepartment
    * ji...@mi...

should do what you expect iff the page "TheHumanResourcesDepartment"
contains somewhere:

    GroupConsistsOf:

    * AlexHamilton
    * TomJefferson
    * ge...@ho...

and the "JoeEdelman", "AlexHamilton", and "TomJefferson" pages have an
'email' component in their page metadata.  Nevermind, for now, how it got
there.

These keywords-- "NotifyAboutChanges" and "GroupConsistsOf"-- must occur by
themselves in a paragraph, followed by a colon, and refer only to the
unnumbered list immediately following them.  You can, however, stack them.
For instance:

    NotifyAboutChanges:

    * ArnoldAwl
    * BurtBly
    * CarlCrow

    This is ordinary wiki text.

    NotifyAboutChanges:

    * DaveDrip
    * EddyEck

will email out to all five people when the page is changed.


MORE NEW SYNTAX

1.

That covers changes to a page, but I also need to be able to notify when a
page has a new Category or Badge-- for instance when someone adds "FixMe" or
"NeedsFinancialAssessment" to a page.  So we have:

    NotifyAboutLinks:

    * TheFinanceDepartmentDweebs

2.

And in certain cases I want to send notifications whenever a page has had a
certain Category or Badge for an amount of time-- for instance when "FixMe"
has been on a page for a week and no one has fixed it.  On the "FixMe" page:

    NotifyAboutLinks (older than 1 week):

    * JoeTheFixMeGuy

    NotifyAboutLinks (older than 1 month):

    * JoesBossJim

Re: [Phpwiki-talk] modifying sign-in pop-up dialog

[Tara S. <te...@cl...>]

Jeff Dairiki wrote:


> This is yet another reason we want to move to using our own forms to
> prompt
> for username/password rather than using HTTP authentication to do that =
as
> we
> currently do.


whee, that would be good. any idea when it can be expected? :)

T.


--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://spirolattic.net/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] db error - no visible consequences

[Jeff D. <da...@da...>]

On Tue, 20 Nov 2001 15:32:26 +0100
"Tara Star" <te...@cl...> wrote:

>      * DB Error: unknown error<\li>
>      * (OPTIMIZE TABLE page)<\li>
>      * <\li>
 
> Is it my fault? is it the wiki's fault? is it the db's fault?

You've discovered another bug.  Phpwiki and your older MySQL are
squabbling.  Apparently the "OPTIMIZE" command is only supported
in newer MySQL's.  The reason you haven't seen the error before
is that the OPTIMIZE gets done at random, on about 1 out 
of every 50 page saves.
 
> The page got created, though - I saw that in RecentChanges.

I don't _think_ there should be any bad side effects other than the error
message itself.

> Oh. I might 
> note that I created the page directly by typing the url in the browser 
> bar - could that be the reason?

Red herring, I think.

[Phpwiki-talk] modifying sign-in pop-up dialog

[Tara S. <te...@cl...>]

Lots of my visitors are having trouble signing in, because they don't=20
understand they need to put caps in their username to make it a=20
WikiWord. I've given the explanations just about everywhere I could on=20
the wiki (including the error message), but the best place to do it=20
would be on the dialog box itself.

Can anybody tell me how I can modify the text it presents? Are there=20
settings somewhere in the wiki files I can fiddle with, or is it a=20
completely different chapter?

Thanks a bunch,

Tara
--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://spirolattic.net/
Pompeurs Associ=E9s - http://pompage.net/

[Phpwiki-talk] db error - no visible consequences

[Tara S. <te...@cl...>]

Hi :)

upon editing a new page, I got the following db error:

lib/WikiDB/backend/PearDB.php:653: Fatal[256]: wikidb_backend_mysql:=20
fatal database error

     * DB Error: unknown error<\li>
     * (OPTIMIZE TABLE page)<\li>
     * <\li>

lib/WikiDB.php:513: Notice[1024]: "Optimizing" backend

lib/WikiDB/backend/PearDB.php:52: Notice[8]: Undefined property: _lock_co=
unt

lib/WikiDB/backend/PearDB.php:625: Notice[8]: Undefined property:=20
_lock_count

lib/WikiDB/backend/PearDB.php:653: Fatal[256]: wikidb_backend_mysql:=20
fatal database error

     * DB Error: unknown error<\li>
     * (OPTIMIZE TABLE page)<\li>
     * <\li>


Is it my fault? is it the wiki's fault? is it the db's fault?

The page got created, though - I saw that in RecentChanges. Oh. I might=20
note that I created the page directly by typing the url in the browser=20
bar - could that be the reason?

Any input welcome. Thanks!


--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://spirolattic.net/
Pompeurs Associ=E9s - http://pompage.net/

[Phpwiki-talk] wikipedia moves to a phpwiki ...

[Adam S. <ad...@pe...>]

it's not our phpwiki but it might be interesting to check out anyway.

    http://wikipedia.sourceforge.net/

adam.

[Phpwiki-talk] [phpwiki - Help] Server Error

[<no...@so...>]

Read and respond to this message at: 
http://sourceforge.net/forum/message.php?msg_id=492984
By: xholli

Hi!
I've got Problems with the Apache Server. I can see all the pages but login
and file upload is impossible. I always get an internal server error. Does anybody
know this problem? What functions are called causing this (security??) problem?
Hope somebody can help me!
Holger

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit: 
http://sourceforge.net/forum/monitor.php?forum_id=18929

Re: [Phpwiki-talk] variable for page name?

[Tara S. <te...@cl...>]

Jeff Dairiki wrote:

> On Fri, 16 Nov 2001 17:15:02 +0100
> "Tara Star" <te...@cl...> wrote:
>=20
>=20
>>I'm preparing a private wiki in which I'm going to allow certain pages=20
>>to be visible to the public. I'm doing it (rather clumsily, I'll admit)=
=20
>>by putting the whole page display into a control statement, like this:
>>
>>if ($user->is_admin() || array_search($pagename, $public_pages))
>>
>=20
> I think you want:
>  if ($user->is_authenticated() || in_array($PAGE, $public_pages))
>=20
> (I'm assuming you want anyone who is "signed in" to be able to see all
> pages.)


Actually, no. I want myself (the admin) to be the only one able to see=20
all pages, /except/ for the public pages which anybody can view.

Your line works fine though (with modification):=20
http://climbtothestars.org/pim/BookMarks (please don't comment on the=20
colours, they're ugly, I know, I'm going to find some better ones).

Tara




--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://spirolattic.net/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] standards-compliant lists

[Jeff D. <da...@da...>]

On Thu, 15 Nov 2001 12:48:34 +0100
"Tara Star" <te...@cl...> wrote:

> I can't find my way in the code to do this, but this is how nested lists

> could be made standards-compliant.

I think I've now kludged things enough to get this right.
(I've just checked my changes into the CVS repository.)

[Phpwiki-talk] SpiroLattic

[Aredridel <are...@nb...>]

Well, I just actually looked at SpiroLattic on a "Real Browser" (I usually
use the text-mode w3m browser, since it's small and fast (and on my P150,
that's rather nice), and since my memory moduel in my machine died, I can't
even manage graphics mode. Anyway, I just looked at the site, and I'm
-really- impressed.  I think I'm going ot be redesigning the NBTSWikiWiki
soon, perhaps, with some inspiration from you.  It's been about time anyway.

I was just playing around with Apache and discovered one other way to make
PHPWiki work as the root of a domain: the ErrorDocument directive.  It's
a weird hack, but it'd work.

You'd put:

	ErrorDocument 404 /phpwiki/index.php
	DirectoryIndex HomePage

in your httpd.conf, and make a few tweaks to PHPWiki:

	$PATH_INFO = $REQUEST_URI;
	Header("HTTP/1.1 200 OK");

in the index.php, I'd guess, though I'm not sure since I didn't actually try
it with anything but a phpinfo(); script.  (If PHPWiki uses 302 redirects
by default now (I honestly haven't had a chance to look), it'll break those,
but otherwise, it should work like a dream, and to override the wikiness of
a URI, just put the file in the directory, and a 404 will never trigger.

The downside is that this doesn't override apache's errorlogging, so you'd
have to deal with that.  Probably not a big deal with a wiki-only site --
just turn it off and use the accesslog or turn it on as neccesary.

Ari

Re: [Phpwiki-talk] xhtml-compliant wiki

[Adam S. <ad...@pe...>]

> So, out of the box: no Javascript, no fancy CSS. Please. We can pack
> in all we want though, and make it easy to enable. By all means,
> stylesheets and Javascript only supported in Mozilla would be most
> welcome by me! :-)

here's a nice mozilla/ie one :)

  <body ondblclick="location.href='/PageName?action=edit'">

it's actually pretty nice to be about to double click the background of
the page and have it open up in the editor.  and surprisingly i never did
it by mistake.  also none of the older browsers seemed to care.

i had it on my wiki for a week or so until i discovered that my hack broke
the ability to search and i haven't gotten around to fixing it.

adam.

Re: [Phpwiki-talk] forum posts -> phpwiki-talk

[Jeff D. <da...@da...>]

On Fri, 16 Nov 2001 12:34:10 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> Does anyone object if posts
> to Open Discussion and Help are automatically posted to phpwiki-talk?

I don't have strong feelings, but I'd vote against it.

1. People can already monitor the forums by e-mail if they so choose (by
clicking on "Monitor Forum").

2. Some confusion may result from the fact that posts to phpwiki-talk
aren't gated back the other way.
   
It would/will be nice to be able to sign up e-mail notification lists for
all the "trackers" (of which there are four: bugs, support, patches and
tasks).  I think it would be fine if new items for all four trackers where
posted to a single list (e.g. phpwiki-bugs).


On a related note, I think there are currently too may redundant forums,
mailing lists,
and trackers. 

  o. The help forum, the support tracker seem to overlap completely.
  o. The discussion form and phpwiki-talk overlap fairly completely.

There's just too many places to look for information.
I don't know whether or not it's possible, but I think it would be nice
to get rid of a couple of these.

On the other hand.  It's not a big deal...