Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
None
Description
from: https://github.com/phonegap/weinre/issues/14
pmuellr opened this issue July 19, 2011
The current weinre extension system is based on the WebKit Web Inspector extension system. It's not working out very well.
Based on trying to write a few extensions, I've come up with the following list of requirements for the extension system.
- extensions loaded as .js files injected into the client, not .html files added via an otherwise unused iframe; implication is that extension code runs in the main Web Inspector window, which is dangerous, but delicious
- extensions are notified when a target connects or disconnects
- extensions have an API to call returning an indication if a target is connected
- extensions can load .js and .css files, relative to the extension directory, into the target, by name; these files will only ever be injected one time in the target, regardless of how many times they are requested
- a callback system for communication from the target to the client is required; clients can register a callback, as a one-shot or multiple-shot callback, as a function, returning an id; the id can be passed to the target, which will have an API to fire the callback by id.
Not much of the Web Inspector extension API is in use right now - seems like we can just create a new set of IDL interfaces to handle this stuff.
davejohnson commented August 03, 2011
This all sounds about right to me.
pmuellr commented October 13, 2011
Unspecified in the initial description is where the extensions come from in the first place, and how the client knows about the available extensions.
In the current level of code, the server provides the extensions, but this is no fun. It requires any server a user might be using to have the extensions they want to use available. This would be a PITA for debug.phonegap.com, for instance.
Instead, the client should be the thing that loads the extensions. This implies a couple of things:
- The client has to remember any extensions the user has "installed". We'll store these in a WebSQL DB associated with the client page, and thus associated with the client's origin - the weinre server. So, the user will have to install the same extensions on their "debug.phonegap.com" client, as well as their "localhost:808x" client. PITA. But survivable. We should consider what it might mean in the future to have a separate "extension" server that the user could use to maintain their extensions across multiple client origins. Keep this in mind while designing this bit.
- We will need to provide a new panel for extensions, that shows you installed extensions, with the ability to add / delete / disable / enable extensions.
- The extensions will need to be available via HTTP. Presumably the server can load these (and cache them?), and then provide them to the extension code via the new extension API.
- Items above seems to imply some meta-data will be required - names, descriptions, versions, etc. Could we package extensions as "npm" packages? Or at least reuse their existing "package.json" structure? Note that modjewel is installed on both ends, so "module" style JS authoring is a distinct possibility. OTOH, we do need a way to load rando JS files, so you can bridge an existing thing like "DOM Monster" with a thin shim extension (actually, DOM Monster is not a good candidate for this - poor separation of model/view).
pmuellr commented October 13, 2011
Would be nice if I could publish extensions as versioned/labelled/whatever GitHub repos. In addition, we could use a Gist to list the extensions a user wants installed.
This doesn't have to be, nor should it be, tied to GitHub. But it would be nice if it would work directly off of GitHub, with no other "exporting" of resources being required.