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.

Driving Needs

In the next generation based on Tim Starling's FileRepo concept, I would like to avoid the issues raised by Brion Vibber (see below), but we 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

Examples of Utilization

• Academic Community - A concept/process is being developed by a select group of users. Until such time as it is published, there may be proprietary/intellectual property issues that should not be dessiminated outside of designated group - including papers, scientific data . . .
• Government - A department wishing to develop a procurement wishes to develop the requirements for a product or service, but wishes to remain compliant with FARS or other rule sets which require fair and open competition. Limiting the conceptual development and specification process to a designatedl authorized internal group while excluding those who might potentially inappropriately influence the specification process is essential to a fair and open competition. This often requires other documents, data . . .

Heart of the Conceptual Issue

In many ways this is antithetical to the concept of openness - but there are times when exclusion is necessary for privacy, security and various other valid reasons. This does mean this feature should be used with the utmost hesitancy, and only when absolutely necessary.

------- Comment #14 From 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.

I agree with Brion and would like to find some type of tagging/categorization. However the concept of NameSpaces has seen wide acceptance and utilization as a mechanism.

The core problem is that somehow, these files must be identified as being part of an exclusive group. If the NameSpace approach is used, both the articles and the associated files can be protected using existing mechanisms.

If we use either a tag or even a new namespace (e.g., ProtectedImage:text.pdf), not only would a new namespace or category be required, but the protections on that category must be synchronized and maintained.

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.pdf)
2. Create Image Namespaces (eg., {ImageNS}:{Image Name} - TestImageNS:test.pdf)

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 (Create New Local Repository Functions)

The beta of this has been released, see Extension:NSFileRepo.

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 (see above)

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?