[
https://issues.apache.org/jira/browse/CB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jcesarmobile closed CB-86.
--------------------------
Resolution: Won't Fix
Closing as cordova-weinre is being deprecated and no more work will be done
> extension system needs to be redesigned
> ---------------------------------------
>
> Key: CB-86
> URL: https://issues.apache.org/jira/browse/CB-86
> Project: Apache Cordova
> Issue Type: New Feature
> Components: cordova-weinre (DEPRECATED)
> Reporter: Patrick Mueller
> Assignee: Patrick Mueller
> Priority: Major
>
> 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 was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
