[pmwiki-users] PmWiki namespaces

Eemeli Aro eemeli at gmail.com
Mon Aug 31 05:08:09 CDT 2009

2009/8/31 Petko Yotov <5ko at 5ko.fr>:
> On Saturday 29 August 2009 14:25:29 Eemeli Aro wrote:
>> Note also that I'm not asking whether namespaces *should* exist; their
>> non-existance is a problem for me that I intend to solve.
> Namespaces do exist in PmWiki, only we call them WikiGroups. :-)

To an extent, yes, but that's not enough for me. Mainly this is a
problem that comes up when you have more than one set of related, but
separate content on a single server, where a WikiFarm approach makes
more sense than keeping all the data in a single wiki. In other words,
cases where you need a higher, second level of grouping. If you try to
cram everything into one wiki, you lose a significant amount of
customizability: group-level authentication and groupheaders &
-footers, as well as having different root URLs for different wikis.

Now, the reason(s) I'm working on namespaces (or whatever they end up
called) comes up in the situation when you have some content that's
shared or accessed between more than one of these wikis on the same
farm. Most of the issues related to this are solved by Sisterly, but
I'm not happy about the level of cognitive dissonance
(Something:Something can be interpreted in at least three completely
different ways) and custom re-wiring of PmWiki internals that's
required. Added to that, I want a way of figuring out which PageStore
a specific displayed page is coming from, a way to move or copy pages
between PageStores, and an attachment system that presents itself as a
seamless part of this whole. Also, I figure that as a side product of
all this I can get a system that should make creating & maintaining a
WikiFarm as easy as adding a few lines of code to a config file.
Backwards-compatible with the current PmWiki system, of course.

>> I'm working on a new way of handling attachments in PmWiki that would
>> make file meta information (filesize, mime type, copyright, etc.)
>> accessible and to some extent editable from within PmWiki (with eg.
>> {Attach:Site./pmwiki-powered.png$MimeType}).
> ...
>> adding a custom PageStore for attachments
> A while ago I was asking myself the same questions (great minds think alike).
> I didn't imagine a custom PageStore for attachments, but a dedicated
> wikigroup, or even more simply, a specially formatted *.RecentUploads page.
> I was thinking, this could possibly be done in a special wikigroup, one page
> per file, with normal PageTextVariables containing the metadata (uploader,
> date, source, copyright, mime, filesize, pixels, seconds...). [snip]
> A custom PageStore could have some advantages, like storing the metadata in
> page attributes.

I think the implementation would be easier as a separate PageStore,
since then you could overload the default read and write methods to
automatically generate and maintain the page contents. Also, much of
the information about a file doesn't really make sense to present as
user-modifiable data (eg. filesize, image width). For another reason,
these file properties are much closer to page attributes rather than
page text variables. And finally, each of these file information pages
is closely tied to the attached file in question, so removing or
renaming an attribute file would be much easier in a custom PageStore.

To clarify, I do agree that all that I'm looking for here is doable
with some patching to the current model and by using PTVs and markup
expressions, etc.  However, I think that changing some of the
fundamentals would in fact be easier, and present a more cohesive
whole. There's a lot of potential in page attributes and custom
PageStores that I think isn't being exploited as well as it could be.

> Unfortunately, the logging/tagging will only work for files uploaded via
> PmWiki, not for those transferred via FTP/SSH. But we could have automatic
> attach-lists identifying those files which lack metadata.

Ah, but that's where a custom PageStore could really help. Take a look
how <http://www.pmwiki.org/wiki/Cookbook/PageTopStore> fundamentally
assumes that changes will be made outside of PmWiki, and integrates
those changes into PmWiki along with change histories.

>> How should namespaces be identified? With Sisterly I use a prefix
>> "WikiName:" that matches Attach: and Intermap links, as well as how at
>> least MediaWiki handles namespaces, but is there a better way?
> Namespaces in MediaWiki are a dozen pre-defined prefixes which are excluded
> from the default search. Category: is very much like ours, User: is like our
> Profiles, MediaWiki: contains interface translations like our XLPages, File:
> contains information about the uploaded files (one upload directory for the
> whole wiki). Also, in MediaWiki, always the full [[Namespace:Page_name]] link
> should be written, even if the current page is in the same namespace.
> I see no advantages of MediaWiki namespaces over PmWiki WikiGroups. Except, as
> mentioned above, for the uploads -- for tracking who uploaded what and when.

MediaWiki I only mentioned because superficially the syntax is
similar. For a more specific example of what I want to achieve, I have
a wikifarm with multiple wikis. Two of these make up a department site
(two languages) and a third is the site of a research group ("ATL")
under this department. The current syntax I use for linking to the
page Research.FSR on the research group site from the department site
is "[[ATL:Research/FSR|+]]". Is there a better way of expressing that?


More information about the pmwiki-users mailing list