strawman API proposal

[bcolloran]

(@hamilton @DevinBayly )

Messages that the webextension should listen for from text-editor-plugins

{ type: “REPLACE_ALL_JSMD”, textContent }
{ type: “INSERT_TEXT”, cursorPosition, text }
{ type: “DELETE_TEXT”, cursorPosition, numCharsToDelete }
{ type: “EVALUATE_CHUNK”, cursorPosition }

Messages that the webextension would send to text-editor-plugins from iodide

{ type: “TEXT_UPDATE_FROM_IODIDE”, textContent }

[bcolloran]

@DevinBayly to clarify some of the assumptions above:

i expect the architecture will be something like:

• the user has a text editor that supports plugins of some kind
• for each different text editor, a plugin will need to be written to do iodide stuff
• a webextension will need to be added to the user's browser to enable messages sent from the text-editor-plugin to be forwarded to an instance of Iodide running in a browser tab (and vice versa)
• in terms of actually sending messages back and forth, the text editor plugin might run a localhost server that the webextension would connect to, or maybe communication could be done using a websocket or something like that. i'm not sure of the details -- this is something that would need to be explored -- but my initial understanding is that because of the restrictions on webextensions, the text-editor-plugin would need to run some kind of server [edit: because i don't think webextensions can talk to local binary programs, i think they need to talk to things that use web protocols. but that could be a misunderstanding.]

the first comment in this issue just lists some of the messages that we'd probably need to send back and forth.

[bcolloran]

To add a little more detail about what will need to happen within iodide:

• we'll need to add code to iodide that listens for message events from the webextension. this might look like the code in e.g. port-to-editor.js. we might even want to generalize those mechanisms and directly extend that code to look for messages from multiple sources.
• once the message has been received by the iodide editor code, it will need to dispatch a redux action to update the application state (again, dispatching redux actions upon receipt of a message is modeled in port-to-editor.js).
• we'll have to write a new redux action (or more likely, a new redux thunk) that handles the case of updating the JSMD by inserting/deleting characters at some position in the buffer. this can then dispatch updateJsmdContent(text) with the new text