Some really rough notes on making a text (and possibly wysiwyg) editor with a site-neutral plug-in system

gistfile1.txt

navigator.registerProtocolHandler('web+texteditorplugin', window.location.href.replace(/\?.*$/, '') + '?pluginInfo=%s', 'Text editor plugin');

// http://127.0.0.1/TextMunger2/index.html?pluginInfo=web%2Btexteditorplugin%3Aurl%3Dhttp%3A%2F%2Fbrett-zamir.me%2Ftests2

// Todo: use back-up for clicks on protocol handler



/*
Todos

1. README: Note that globalStorage would have been better but a protocol at least makes it similarly neutral
1. README: Note possibility for content-type handlers for the text editors themselves
1. README: Mention ultimate desirability of Browser UI (through Browser API?) using such web-extensibility
1. Feature discovery for postMessage (e.g., edit only capability) or bake into protocol?
1. Note and implement live, cached with updates, cached with no updates
1. Note and implement privileged and non-privileged (with non-privileged being either simple JSON or eval in sandbox to return JSON)


The purpose of the project is to allow the user to collect plug-ins that he wants to use, but without forcing him to always use the same text editor. For example, he might collect plug-ins which can build a button which will convert text to upper case or will convert Unicode into entities.


Steps

1. A site ABC uses registerProtocolHandler() to register a protocol; let's call it "web+texteditorplugin". This protocol will be used to collect a list of all plug-ins. We use a protocol instead of an http URL so that the user can decide to use other text editors later which will still be able to use the same list of plug-ins.

2. A site DEF offers a text editor (one that can also work offline) that uses the protocol of ABC to communicate with plug-ins. (DEF could be the same site as ABC and offer to register the protocol itself, but I'm using an example with a different site to make things clear.)

3. The same site, or another site, let's say, XYZ, offers links like this which allow plug-ins to be added:

    <a href="web+texteditorplugin:url=http://example.com/location-of-plugin">Add text editor plug-in</a>

4. When the user clicks on those links, the site ABC will be opened with the URL, and ABC will ask the user if they wish to store the plug-in URL (in its localStorage).

5. The user can visit other sites and add more plug-ins.

6. When the user goes back to site DEF to use the text editor, the text editor will try to postMessage with "web+texteditorplugin" (which is now site ABC for this user) to find out what plug-ins have been registered. It gets back a list of URLs that the user has confirmed. DEF then opens hidden iframes to do cross-domain postMessage with the plug-in URLs that ABC gave to it (e.g., http://example.com/location-of-plugin ) in order to either get that site's plug-in code (to keep a copy itself and maybe ask for updates later) or to pass on some text live to the site to get modified text back.

7. The plug-ins could be:
    1. Simple converters that return a JSON object, and can thus be safe and trusted to do only what the API allows (e.g., convert some text).
    2. eval() code but which is run in a sandbox (see http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ ) and has to return JSON only, so it is also safe.
    3. Privileged plug-ins which will be run with eval() so that they can modify the editor in any way desired. The editor will ask the user permission to use the plug-in in a privileged way (or maybe there should be a separate protocol for privileged plug-ins).

*/