extension system needs to be redesigned
---------------------------------------
Key: CB-86
URL: https://issues.apache.org/jira/browse/CB-86
Project: Apache Callback
Issue Type: New Feature
Components: weinre
Reporter: Patrick Mueller
Assignee: Patrick Mueller
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
