Setting up wiki to accept key proposals
brettz9 opened this issue · 2 comments
One other approach you might take (instead or maybe even in addition) is to just open up your wiki to allow people to register their own keys as WhatWG is doing with http://wiki.whatwg.org/wiki/MetaExtensions. While there might be a greater chance for conflict than with genuine domain-based namespaces, it might also invite some people who wouldn't be interested otherwise, e.g., because they didn't want to force everyone using the convention to be associated with a particular website, they didn't want to acquire a site for the purpose, or they just wanted short sleek keys names.
(FYI, I've started something similar at https://github.com/brettz9/webappfind/wiki/Registered-file-types and https://github.com/brettz9/webappfind/wiki/Registered-custom-modes )
On the other hand, I do see that some sites may not be interested in trumpeting info about their keys (even if not private), so formal, domain-based namespaces could I think still be useful for that reason as well.
Also FYI, and as I plan to mention on the Mozilla blog, I have started on some code for facilitating neutral shared localStorage as a kind of stand-in for the now gone globalStorage for the sake of facilitating offline storage that can be shared across domains as well as within a site. It has to be hosted on a site that the parties trust, but maybe a CDN could be a possibility (and by using app cache to cache the HTML and JS, it ought not get too high of traffic over time). In this system, I have set up different types of shared spaces, a read-only type (with set privileges only for the domain at the origin) and a fully neutral shared type.
It's a real pity imo that Mozilla didn't keep such a neutral storage in the browser as globalStorage, as privacy concerns ought to be overcome by providing, e.g., as I am hoping to do, prompts requiring user permission for any setting of storage as well as retrieval. Possible use cases include building your own add-on system (such as at http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ ), but with the storage in a neutral third-party territory rather than belonging to one implementation. Imagine sites/web apps storing preferences, document drafts, etc. following shared conventions without them belonging to a single site. User data would no longer be locked into walled data gardens, but introspectable and editable by the user (such as with localStorage Firefox add-ons) and, as with our good old operating system's file system, store data in a manner which does not give precedence to any particular application (i.e., no need to postMessage to a particular implementer's site).
If you like, I can update you when it is ready to be documented.
And one last item...you might add in mention encouraging that documentation be made at the namespace even if libraries shouldn't require resolving the namespace by causing users to visit it (as some bad XML namespace implementations had done).
This is excellent feedback and I'll be thinking about it.
As far as your last comment are you suggesting that we encourage for example someone to put doco at superlibrary.whatever.com if that is the namespace they use?
On Feb 21, 2014, at 5:57 AM, Brett Zamir notifications@github.com wrote:
One other approach you might take (instead or maybe even in addition) is to just open up your wiki to allow people to register their own keys as WhatWG is doing with http://wiki.whatwg.org/wiki/MetaExtensions. While there might be a greater chance for conflict than with genuine domain-based namespaces, it might also invite some people who wouldn't be interested otherwise, e.g., because they didn't want to force everyone using the convention to be associated with a particular website, they didn't want to acquire a site for the purpose, or they just wanted short sleek keys names.
(FYI, I've started something similar at https://github.com/brettz9/webappfind/wiki/Registered-file-types and https://github.com/brettz9/webappfind/wiki/Registered-custom-modes )
On the other hand, I do see that some sites may not be interested in trumpeting info about their keys (even if not private), so formal, domain-based namespaces could I think still be useful for that reason as well.
Also FYI, and as I plan to mention on the Mozilla blog, I have started on some code for facilitating neutral shared localStorage as a kind of stand-in for the now gone globalStorage for the sake of facilitating offline storage that can be shared across domains as well as within a site. It has to be hosted on a site that the parties trust, but maybe a CDN could be a possibility (and by using app cache to cache the HTML and JS, it ought not get too high of traffic over time). In this system, I have set up different types of shared spaces, a read-only type (with set privileges only for the domain at the origin) and a fully neutral shared type.
It's a real pity imo that Mozilla didn't keep such a neutral storage in the browser as globalStorage, as privacy concerns ought to be overcome by providing, e.g., as I am hoping to do, prompts requiring user permission for any setting of storage as well as retrieval. Possible use cases include building your own add-on system (such as at http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ ), but with the storage in a neutral third-party territory rather than belonging to one implementation. Imagine sites/web apps storing preferences, document drafts, etc. following shared conventions without them belonging to a single site. User data would no longer be locked into walled data gardens, but introspectable and editable by the user (such as with localStorage Firefox add-ons) and, as with our good old operating system's file system, store data in a manner which does not give precedence to any particular application (i.e., no need to postMessage to a particular implementer's site).
If you like, I can update you when it is ready to be documented.
And one last item...you might add in mention encouraging that documentation be made at the namespace even if libraries shouldn't require resolving the namespace by causing users to visit it (as some bad XML namespace implementations had done).
—
Reply to this email directly or view it on GitHub.
Sorry, I meant to get back on this earlier. Yes, that is the suggestion.
FYI, there is a precedent with this as far as XML namespaces which though normally not meant to be resolved, since people often were resolving them, the idea came for RDDL, an extension of XHTML Basic, to describe them (where the RDDL page would also be semantically marked up to indicate what different types of resources like stylesheets, executables, etc. were available for use with the namespace):
Per the spec, "A Resource Directory is designed to be suitable for service as the body of an entity returned by dereferencing a URI serving as an XML Namespace name."
Btw, one other idea related to opening up your wiki, though on the centralized rather than decentralized front... Regardless of whether you decide to allow non-site-specific namespaces and their documentation, you could still allow a central place for indicating sites and tools using different namespaces, whatever the format.
I have one tool in mind now which is https://github.com/brettz9/asyouwish/ which allows shared namespace storage across any domain (like globalStorage did before, though it is regrettably not available in Firefox by default, not to mention not standard, and it is accompanied by the ability for sites to request other more potentially dangerous, albeit useful, features upon user permission) and which I might indicate should use the conventions of LSNS and/or reference a shared repository for centralized namespace documentation.