[pmwiki-users] Re: How to 'automatically' keep a deployed PmWikiinstall up to date?

[Crisp, Steve [UK]]

Thanks everyone for the analysis to date all very constructive.  More of my comments below:

 

Patrick R. Michaud on 26 September 2005 21:44, wrote:

 

> First, I'm not a big fan of anything that attempts to actually

> install updates -- there are just too many potential pitfalls and

> security problems.

 

Totally agree now on the grounds of security and, as Christian Ridderström reminded us all, that the user account running PmWiki is unlikely going to have permission to do this anyway!

 

> However, automatically identifying and notifying of new recipe

> versions sounds reasonable to me if people are willing to go

> through the effort of maintaining such a thing.  :-)

> 

> An important question arises as to whether admins want to follow

> just the recipe code itself or the Cookbook pages describing the

> recipes.  For example, if I have the CompressedPages recipe

> installed, I may be interested to know when new information is

> posted to the Cookbook page even if the recipe itself doesn't

> change.

> 

> Bronwyn is correct that we may be able to solve a large portion

> of this using RSS and/or trails.  And we can probably create

> some special actions on pmwiki.org to report recipe versions.

> So, we might want to investigate that further.

> 

> Another possibility that solves a more generic problem is to

> come up with a watchlist and/or automatic page notification feature.

> In other words, individuals are allowed to "subscribe" to pages

> of interest (Cookbook pages in this instance) and automatically

> receive notification of some sort when the page is changed.

> (This has been discussed somewhat at

> http://www.pmwiki.org/wiki/PITS/00358,

> although I disagree strongly with many of the design/implementation

> suggestions posed there.)

 

In analysing this requirement we are starting to see that existing features of PmWiki can be reused in combination with new.

 

I already use the fantastic RSS feeds, both to monitor the external PmWiki site and our internal PmWiki-based intranet.  For now I've settled on an RSS ticker called wTicker (note, a little fiddly to configure).  I have two tickers displayed - one for each Wiki.  The PmWiki ticker is configured to 'watch' specific pages i.e. all pages I have used to configure my Wiki.  For me this solves watching the cookbook pages.

 

The disadvantage of this approach is the extra load it puts on the server when you scale up this kind of activity - it's a polling mechanism (once per day configured for me) not the better event based solution Pm describes above.  To subscribe to pages and be emailed when they changed would be great enhancement to PmWiki especially in my case within our private intranet.

 

> But lacking those, there is some merit in the idea of establishing

> a standard "version" array where recipes can store version information.

> I'm thinking something simple like:

> 

>     # information for the pagestoregz recipe

>     $Module['pagestoregz'] = array(

>       'version' => 21,

>       'uri' => 'http://www.pmwiki.org/wiki/Cookbook/CompressedPages',

>       'desc' => 'Store pages as compressed text');

> 

>     # information from lightskin

>     $Module['lightskin'] = array(

>       'version' => 13002,

>       'uri' => 'http://www.pmwiki.org/wiki/Cookbook/LightSkin',

>       'desc' => 'A lean, content-based skin');

> 

> But it's not entirely clear what to do with this information once

> we have it.  It can certainly be used to tell an administrator

> what recipes are being installed on a given page (and where to

> check for updates).  Having an automatic check with pmwiki.org

> for updates requires slightly more work, plus a decision as to

> what constitutes an "update" requiring notification and how

> that should take place.

 

The above collection of 'version' arrays seems a simple and effective solution with minimal impact on recipe authors.  One might also want to add to the above an 'update_uri' item that links to the latest download of the file or archive for a recipe.

 

Good point about what to do with it all now??  Everything needs to be programmatically determined from this point on.

 

My first embryonic thoughts when I started this were to use a 'trusted mark-up' which scraped the latest version information from a regular page on the PmWiki main site.  This page could be the actual cookbook page or a centralised cookbook register page.

 

I still think that displaying the version of installed recipes against what is available to the admin would be a big step in the right direction.  Leave it up to the admin to interpret the results and take action.  Let me explain more ...

 

1. Assume all recipe pages include a single line identifying the latest stable release: e.g. 

 

      !! Latest stable Release

      Version 0.06

 

2. Assume a Wiki rule or guideline is introduced to set an anchor within a recipe page to locate the line describing the latest stable release e.g:

 

      !! Latest stable Release

      [[#latest-stable]]

      Version 0.06

 

3. Assume changes are made such that the following mark-up (I'll call it 'trusted mark-up' - explained later) will display a single page listing the latest-stable release.

 

Mark-up:

 

      (:include PmWiki:Cookbook/LightSkin #latest-stable lines=1..1 :)

 

Displays a page with:

 

      Version 0.06

 

4. Assume one adds another item to Pm's 'version' array which captures the above 'trusted mark-up' associating it to a recipe.  Plagiarising Pm's example:

 

  # information for the pagestoregz recipe

  $Module['pagestoregz'] = array(

    'version' => 21,

    'uri' => 'PmWiki:Cookbook/CompressedPageStore',

    'desc' => 'Store pages as compressed text',

    'update_uri' => 'PmWiki:uploads/Cookbook/pagestoregz.php',

    'latest_version_lookup' =>

        '(:include PmWiki:Cookbook/LightSkin #latest-stable lines=1..1 :)'

  );

 

5. Final assumption (promise) is that a few simple php lines written by someone much more capable than I could present a single page to the admin user with links to all the information he might need to manually update a system.  As you iterate over the version array the 'latest_version_lookup' element should be resolved and combined with the other information - viola!

 

Apologies if this is a rambling - just trying to keep it simple and maintainable with minimal new development.

 

If anything is not clear just let me know and I'll clarify.

 

Thanks for listening,

-Steve.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20050928/92fce140/attachment.html