cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Mueller (Created) (JIRA)" <>
Subject [jira] [Created] (CB-86) extension system needs to be redesigned
Date Tue, 29 Nov 2011 17:55:40 GMT
extension system needs to be redesigned

                 Key: CB-86
             Project: Apache Callback
          Issue Type: New Feature
          Components: weinre
            Reporter: Patrick Mueller
            Assignee: Patrick Mueller


*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, for instance.

Instead, the client should be the thing that loads the extensions. This implies a couple of

* 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 ""
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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message