User:Jpond/NSFileRepo

NSRepo Concept
The purpose of this extension is to provide NameSpace-based protections to uploaded files.

The optimal solution would be a clean extension that is easily maintainable as the trunk of MW moves foward.

Working Questions/Issues
In the next generation based on Tim Starling's FileRepo concept, I would like to avoid the issues raised by Brion Vibbor (see below), but I still need the functionality. Why?


 * 1) When using MediaWiki as a collaborative tool in a corporate/enterprise environment, there are those who will not participate unless; a) working documents can be withheld until such time as it is ready for widespread dissemination and; b) information can be protected from competitive interests
 * 2) In the government workspace, certain information should not be exposed unless the users/reviewers/editor have a valid need to know (e.g., privacy, security).
 * 3) Individuals will not (for various reasons) participate if their participation was knowable beyond a defined group

Categorization Through Hierarchy
Designatable protection is inherently a form of categorization. The question is how should this be done. In the classical environment, information is stored in a directory structure, then protections applied to the nodes of that structure - a model that is inherently hierachical. This can be expressed in two ways:


 * 1) Allow namespace in image link (eg., Image:[ns]:[Image Name]) - Image:TestNS:Test.txt)
 * 2) Create Image Namespaces (eg., [ImageNS]:[Image Name] - TestImageNS:test.txt )

Categorization Through Tagging
Would love to hear suggestions on how to:
 * 1) Tag images where tags identify namespaces for protections
 * 2) Design a policy/mechanism that would limit "taggers" to those with access to the tagging namespace

Generation 2 Red Herrings
I originally thought that the new repo classes could be extended to support new image namespaces. However, the way they work is to extend the "Image:" and "Media:" namespaces to search through multiple repositories based on the arrayed definition of repos in $wgLocalFileRepo and $wgForeignFileRepos sequentially.

I thought I might do something like:

Where TestImage would be a defined NameSpace and NSRepo extends LocalRepo

I'm beginning to have real doubts about this approach because you still have to have a mechanism for uploading or protecting a file which identifies it as being in NameSpace 'TestImage'.

Generation 1, 2007-05
If namespaces were allowed as sub-categorization of images, a large number of features could be enabled through extensions and other customization, including:


 * Namespace protection on images (updloaded files)
 * Categorization, sorting, search by namespace (and category) of images
 * Tree-structuring of images (eg, sub-directory type listings using NS and designated categories)

The originally proposed mechanism was two-fold:


 * 1) Allow namespace in image link (eg., Image:[ns]:[Image Name]) -
 * 2) Include namespace in file hash (eg., [ns]/[category]/[hash]/file.img

Changes were made, implemented in production on ~15 wikis, but wasn't possible to sustain it as a parallel branch of MW.

The original objections are concise and completely understandable:

--- Comment #14 From [mailto:brion@wikimedia.org Brion Vibber] 2007-05-14 15:10:39 UTC ---

This seems too hierarchical and hard-wired, the opposite of the sort of categorization and tagging we like to see on a wiki.

I don't see it as being very useful.

Originally submitted as an enhancement - (wontfixed)
This functionality can be implemented by patching 4 files and is completely reverse compatible with previoius versions. Additionally, the proposed patches require this functionality to be enabled (disabled by default), and poses almost no overhead when not used.

It provides a platform for much needed image categorization, including enhanced listing and segregation with very little cost.

Modifications:

SpecialUpload.php - modify to allow uploading of image using [ns]:[Image Name] format, assign to ns, and save in [ns]/[category]/[hash]/file.img hashed format Image.php - parse ns/category in image reference (if exists) ImageFunctions.php - parse ns/category in image reference (if exists) Title.php - needs two set property functions

Optional:

img_auth.php - enhance to use enhanced hashing or (preferable), new img_authNS.php which does same with NS protection checking (old img_auth would still work, just wouldn't have overhead/functionality of NS checking).

--Jlcaune 15:58, 21 October 2007 (UTC) I am very interested by this patch. Do you have something working with MediaWiki 1.11.0?