Wikimedia Bugzilla is closed!

You don't need to have it in RL to be useable...

Generally we only add modules to core if core is going to use it, or many extensions do...

I'm another Javascript extension developer on commons and would find this module very useful to streamline my code that currently relies on cookies to store clientside data. 

This should be a pretty low-maintenance addition, and it would be pretty helpful for script developers. 

What is you suggestion to use it without being in RL? Copying the code verbatim into every gadget page?

(In reply to comment #2)
> I'm another Javascript extension developer on commons and would find this
> module very useful to streamline my code that currently relies on cookies to
> store clientside data. 
> 
> This should be a pretty low-maintenance addition, and it would be pretty
> helpful for script developers. 
> 
> What is you suggestion to use it without being in RL? Copying the code verbatim
> into every gadget page?

No, have it on one page and use importScript/similar to have it where you want to use it. Like is done in many places currently...

importScript is last century. It loads asynchronously and provides no way of supplying a callback.

Now if mw.loader.using would allow for arbitrary URLs like mw.loader.load does (this is an API inconsistency in my opinion), then we'd be talking.
There are many possible cases, where a script would have check the client-side stored values _before_ any user interaction is made (i.e. to display a customized user interface). 

Am i expected to result to ugly setTimeout loops to check if my required objects are already imported?

If you can't use ResourceLoader and need callback:

Use $.getScript( '//url/here', function() { ... called when scrip url is downloaded and executed });

If you can use ResourceLoader (gadget), add it to the MediaWiki namespace and add it as a file or dependency in your gadget. The latter is recommended and will minify and concatenate it before your script.

To use a module there is no need to put everything in core. Try it locally first. 

btw, another idea. If you can't use resourceloader, you can also create a gadget called jStorage and add [ResourceLoader] to it. Then you can use 'ext.gadget.jStorage' in either [dependencies=] or mw.loader.using().

Aside: What is jStorage offering that localStorage doesn't offer? (browser support of course, but other than that? You could do feature detection and only serve to modern browsers, support is growing rapidly[1]).

The way to use localStorage is basically the same (jStorage uses localStorage if available).

Marking WONTFIX for now. We can always add it later to core if we need it.


[1]: http://www.html5rocks.com/en/features/storage

Huh... you are too fast with closing before I could give you some more arguments:

* This plugIn supports storing XML, and almost any type of javaScript variables.
* This plugIn supports all major browsers that are in use, including Internet Explorer 6 to 8
* If you offer it now, you can avoid causing the next mess. I think it is simply wrong to say "Let's wait until the whole world is using its own implementations and then add support for it and deprecate the whole world."

I understand that you don't want unnecessary maintenance in your core. But storing data on the client side is a *core* requirement if you want to write smart applications. I would even offer to bring the whole code in compliance with your Coding Conventions if you agree to add it.

I know about the ability of importScript, the ugly gadget-(BTW, can I add |rights=nobodyHas to avoid display?), jQuery events and XHR/eval-tricks. Most of them work site-wide. Go to the next site and nothing works or you have to duplicate the code.

I find it a bit unfair that while the UploadWizard-monster is allowed to add dozens of modules (such as arrow-steps, mw.api that adds no benefit over directly using a XHR and do a bit smart error-handling) to core, while you consider the pile of jQuery-effects as more important, you deny this.

(In reply to comment #7)
> [you] deny this.

I'm not denying anything. However usually things are used before they are added to core, not the other way around.

Also, modules can be loaded cross-wiki (no need for duplication). This was possible in 1.18 and even more so in 1.19.

I'd say, get it out there. Play with jStorage, see if it fits your need. Give it time to sink in, perhaps other contributors to the script find an alternative library to use or whatever. No need to rush anything.

Of course I would accept any other plugIn that covers at least the same functions and browsers. I just have this for 2 months in use and got no complaints, yet.

Keywords: HTML5 local storage, client storage, userData

Whahah!

https://gerrit.wikimedia.org/r/#/c/20470/

Done in https://gerrit.wikimedia.org/r/#q,I2343744304191d5846cf346e4ac6ca083a6414b3,n,z

Obviously one must be a Hoo man!