Allow browser-storage plugin enable status to be stored in local storage?

[btheado]

In another thread a few months back, @JanJo used a modified version of the browser-storage plugin’s startup.js to allow the enable status of the plugin to be stored in local storage:

@btheado

And I looked at the code and it looks like that tiddler is explicitly excluded from being saved to local storage:

var ENABLED_TITLE = "$:/config/BrowserStorage/Enabled"

[...snip...]

      $tw.utils.each(filteredChanges,function(title) {
        // Don't try to save changes to our enabled status
        // (If it were enabled in the file but disabled in local storage then we might 
        // not realise that distributing a copy of the file would have local storage enabled
        // for other users)
        if(title === ENABLED_TITLE) {
          return;
        }
        // Save the tiddler
        saveTiddlerToLocalStorage(title,{
          logger: logger,
          prefix: prefix
        });
      });

@jeremyruston, I see the javascript is hard-coded to block the $:/config/BrowserStorage/Enabled tiddler from being saved. I take it you found it too easy to accidentally distribute an edition containing that plugin and having it unknowingly enabled?

Would it be enough to instead include -$:/config/BrowserStorage/Enabled in the default SaveFilter? That way by default the enabled setting won’t be saved to localstorage, but it could easily be overridden without changing the javascript code.

[jeremyruston]

Hi @btheado the underlying concern is noted in the comment. I think I implemented the check on the loader side because it seemed more robust.

What are the use cases for being able to store the config tiddler in local storage?

[btheado]

Thanks for the response.

@jeremyruston

Hi @btheado the underlying concern is noted in the comment

Right and I was thinking my proposal might still address that concern and at the same time be possible for the user to override without changing javascript.

@jeremyruston

I think I implemented the check on the loader side because it seemed more robust.

Since the check is in $tw.wiki.addEventListener("change", [...], I was thinking it was implemented on the saver side, not the loader side.

@jeremyruston

What are the use cases for being able to store the config tiddler in local storage?

Good question. I now realize that I don’t think I understand the use case well enough to be proposing a change. The use case came from @JanJo in that thread. The solution he settled on was to comment out the $:/config/BrowserStorage/Enabled javascript check.

I thought changing the default filter would be a better approach than “forking” the plugin and modifying the javascript. But maybe a broader perspective is required.

[TW_Tones]

I have implemented local storage such that the plugin is preinstalled but not activated. The activation is then stored in local storage it worked fine and it did it making use of the configurable filters.

A nice complement to this will be a local backup and restore process for the delta otherwise stored in local storage. ie rather than download the wiki you download only your changes.

Some nice tricks exist to generate a bookmarklet to invoke the wiki such that if the local storage is lost it will help you restore that. If minimalist in size all the local storage could be saved in a bookmarklet, perhaps in future a browser plugin could make use of modern interactions with the desktop.

There is a pile of caveats on local storage