cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 20:51:29 GMT
Good point Don, the requirements should be out of scope for a plugin
developer.
I agree that ultimately this is a choice that the developer should make for
their own app.

@purplecabbage
risingj.com


On Wed, Apr 17, 2013 at 1:22 PM, Don Coleman <don.coleman@gmail.com> wrote:

> On Windows Phone the permission required to access NFC is ID_CAP_PROXIMITY.
>
> The ID_REQ_NFC restricts the application to running on only devices that
> have NFC.
>
> This would be equivalent to setting android:required to true for a feature
>
>     <uses-feature android:name="android.hardware.nfc"
> android:required="true" />
>
> AFAIK android:required="true" only effects Google Play listings.
>
> Plugman should set the features and permissions.  I think adding hardware
> restrictions is a decision that needs to be made by the app developer.
>
>
> On Wed, Apr 17, 2013 at 3:41 PM, Jesse <purplecabbage@gmail.com> wrote:
>
> > I could, or it could just be an ignored tag for other platforms. It will
> > sit inside the platform tag anyway.
> > could also just add an optional attrib to the permission tag :
> > <permission type='requirement'  name='ID_REQ_NFC' />
> >
> > The names already do contain enough info to easily parse, ID_CAP_*
> ID_REQ_*
> > not to mention ID_RESOLUTION_*
> >
> > I am down with whatever.
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Apr 17, 2013 at 12:24 PM, Filip Maj <fil@adobe.com> wrote:
> >
> > > Hmm, this could be an implementation detail for windows phone.
> > >
> > > Requirement vs permission isn't syntactically different. Could we
> > > encapsulate Windows Phone requirements as <permission> elements in
> > > plugin.xml, and have tooling be smart enough to parse wp7 + wp8
> > <platform>
> > > <permission> elements and drop them into the Windows Phone manifest as
> > > whatever elements they need to be?
> > >
> > > On 4/17/13 12:16 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> > >
> > > >While we are there, we may want to add an optional requirements tag.
> > > >Requirements let the app specify what device features it must have,
> for
> > > >example NFC. [1]
> > > >Logically this would just fall right under platform, and be optional :
> > > >
> > > > <platform name="wp8">
> > > >        <requirement name="ID_REQ_NFC" />
> > > >  </platform>
> > > >
> > > >Does it make sense for us to group these?
> > > >ie.
> > > >
> > > ><platform>
> > > >  <permissions>
> > > >     <permission/>
> > > >      ...
> > > >  </permissions>
> > > >  <requirements>
> > > >     <requirement/>
> > > >      ...
> > > >  </requirements>
> > > ></platform>
> > > >
> > > >
> > > >
> > > >
> > > >[1]
> > > >
> > >
> >
> http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/04/17/defining
> > > >-your-app-s-requirements-for-a-great-customer-experience.aspx
> > > >
> > > >
> > > >
> > > >@purplecabbage
> > > >risingj.com
> > > >
> > > >
> > > >On Wed, Apr 17, 2013 at 12:04 PM, Filip Maj <fil@adobe.com> wrote:
> > > >
> > > >> Good call, sound rule of thumb
> > > >>
> > > >> On 4/17/13 12:03 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> > > >>
> > > >> >RE: the permission element
> > > >> >Looks good for wp7 + wp8
> > > >> >I assume if some platform requires extra data in the permission
tag
> > it
> > > >>can
> > > >> >have it, the same way that the blackberry version has the system
> > > >> >attribute.
> > > >> >
> > > >> >@purplecabbage
> > > >> >risingj.com
> > > >> >
> > > >> >
> > > >> >On Wed, Apr 17, 2013 at 11:48 AM, Jeffrey Heifetz
> > > >> ><jheifetz@blackberry.com>wrote:
> > > >> >
> > > >> >> Makes sense to me.
> > > >> >>
> > > >> >> Sent from my BlackBerry 10 smartphone on the Rogers network.
> > > >> >> From: Filip Maj
> > > >> >> Sent: Wednesday, April 17, 2013 2:43 PM
> > > >> >> To: dev@cordova.apache.org
> > > >> >> Reply To: dev@cordova.apache.org
> > > >> >> Subject: Re: plugman + plugin spec final q's
> > > >> >>
> > > >> >>
> > > >> >> K one more update: <permission> element that will be
a child of
> > > >> >><platform>
> > > >> >> elements.
> > > >> >>
> > > >> >> Examples:
> > > >> >> <platform name="android">
> > > >> >> <permission name="android.permission.INTERNET" />
> > > >> >> </platform>
> > > >> >> <platform name="blackberry">
> > > >> >> <permission name="_sys_use_consumer_push" system="true"
/>
> > > >> >> </platform>
> > > >> >> <platform name="wp7">
> > > >> >> <permission name="ID_CAP_CONTACTS" />
> > > >> >> </platform>
> > > >> >>
> > > >> >>
> > > >> >> `name` attribute is mandatory, mapping to native strings
> > representing
> > > >> >> specific features/permissions.
> > > >> >>
> > > >> >> `system` attribute is optional and false by default. Only
used by
> > > >> >> BlackBerry for certain system-level permissions.
> > > >> >>
> > > >> >> I think this satisfies our use cases.
> > > >> >>
> > > >> >> Thoughts/comments welcome.
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> On 4/17/13 11:07 AM, "Jeffrey Heifetz" <jheifetz@blackberry.com>
> > > >>wrote:
> > > >> >>
> > > >> >> >I was thinking exactly along the same lines as Braden.
Whatever
> > > >> >>universe
> > > >> >> >the cordova core plugins live in will likely be default,
with
> the
> > > >>wild
> > > >> >> >west following it. SO long as plugman is explicit about
where it
> > is
> > > >> >> >fetching from, a dev shouldn't have to find the URL and
hope it
> > > >>never
> > > >> >> >changes.
> > > >> >> >
> > > >> >> >On 13-04-17 2:01 PM, "Braden Shepherdson" <braden@chromium.org>
> > > >>wrote:
> > > >> >> >
> > > >> >> >>I think there will be a common repo, where the Cordova
core
> > plugins
> > > >> >>and
> > > >> >> >>some others live. See the spec for the remotes.js
file; I think
> > it
> > > >> >>should
> > > >> >> >>search for plugins with the given name in each of
those
> > universes.
> > > >> >> >>Specifying a url in the <dependency> would
then only be
> necessary
> > > >>for
> > > >> >> >>other
> > > >> >> >>universes.
> > > >> >> >>
> > > >> >> >>Braden
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj <fil@adobe.com>
> > wrote:
> > > >> >> >>
> > > >> >> >>> But then we'd need to be able to discover the
different
> > > >>universes..
> > > >> >> >>>Unless
> > > >> >> >>> we all agree on a "default", don't think this
is optional..
> > > >> >> >>>
> > > >> >> >>> On 4/17/13 10:53 AM, "Jeffrey Heifetz" <
> > jheifetz@blackberry.com>
> > > >> >> wrote:
> > > >> >> >>>
> > > >> >> >>> >Coming back to Braden's suggestion of specifying
a url and
> id
> > > >>for
> > > >> >> >>>plugin
> > > >> >> >>> >dependency, I think this is the correct
route, and would go
> > > >> >>further to
> > > >> >> >>> >suggest the url is optional. I do not believe
we should
> > > >>inherently
> > > >> >>tie
> > > >> >> >>> >plugin dependency to the exact source. Thats
why we have a
> > > >> >>discovery
> > > >> >> >>> >system and multiple places to get a plugin
from.
> > > >> >> >>> >
> > > >> >> >>> >On 13-04-17 1:37 PM, "Filip Maj" <fil@adobe.com>
wrote:
> > > >> >> >>> >
> > > >> >> >>> >>Braden and I had a little chat on IRC
about
> install/uninstall
> > > >>and
> > > >> >> >>>calling
> > > >> >> >>> >>prepare. We've agreed that having prepare
as a separate
> > > >>command is
> > > >> >> >>>useful
> > > >> >> >>> >>(you tweak some plugin JS files, add
more JS files, and
> want
> > > >>that
> > > >> >> >>> >>reflected in your app), but also calling
prepare
> > automatically
> > > >> >>after
> > > >> >> >>>an
> > > >> >> >>> >>install and uninstall makes sense too
(otherwise people
> using
> > > >> >>plugman
> > > >> >> >>> >>will
> > > >> >> >>> >>have to call prepare manually after
calling install or
> > > >>uninstall).
> > > >> >> >>> >>
> > > >> >> >>> >>FTR, --prepare composes the cordova_plugins.json
object
> that
> > is
> > > >> >>read
> > > >> >> >>>by
> > > >> >> >>> >>cordova.js and handles injecting plugin
JS into the app. It
> > > >>will
> > > >> >>also
> > > >> >> >>>be
> > > >> >> >>> >>responsible for handling permissions
that plugins require
> and
> > > >> >>setting
> > > >> >> >>>up
> > > >> >> >>> >>platform manifests appropriately based
on all installed
> > > >>plugins.
> > > >> >> >>> >>
> > > >> >> >>> >>On 4/17/13 10:25 AM, "Brian LeRoux"
<b@brian.io> wrote:
> > > >> >> >>> >>
> > > >> >> >>> >>>Braden: you thinking that the config
is canonical and then
> > > >> >>prepare
> > > >> >> >>> >>>quietly
> > > >> >> >>> >>>does the right thing based on that?
> > > >> >> >>> >>>
> > > >> >> >>> >>>(Agree less steps is exactly what
we're going for here.)
> > > >> >> >>> >>>
> > > >> >> >>> >>>
> > > >> >> >>> >>>On Wed, Apr 17, 2013 at 10:16 AM,
Braden Shepherdson
> > > >> >> >>> >>><braden@chromium.org>wrote:
> > > >> >> >>> >>>
> > > >> >> >>> >>>> Re: --install calling --prepare:
no. It could, though, I
> > > >> >>suppose.
> > > >> >> >>> >>>>
> > > >> >> >>> >>>> Why not have --prepare handle
the plugins rather than
> > > >> >> >>>install/remove.
> > > >> >> >>> >>>>We're
> > > >> >> >>> >>>> trying to make less, not more,
happen at install time.
> > > >>Someday
> > > >> >>I
> > > >> >> >>>hope
> > > >> >> >>> >>>> --install ceases to exist.
> > > >> >> >>> >>>>
> > > >> >> >>> >>>>
> > > >> >> >>> >>>> On Wed, Apr 17, 2013 at 12:59
PM, Filip Maj <
> > fil@adobe.com>
> > > >> >> wrote:
> > > >> >> >>> >>>>
> > > >> >> >>> >>>> > Max, yeah, at the top
of the plugman readme (in both
> > > >>future
> > > >> >>and
> > > >> >> >>> >>>>master I
> > > >> >> >>> >>>> > believe), the usage docs
don't specify --install or
> > > >> >>--uninstall
> > > >> >> >>>as
> > > >> >> >>> >>>>an
> > > >> >> >>> >>>> > available command, but
those commands are referenced
> > right
> > > >> >>after
> > > >> >> >>>the
> > > >> >> >>> >>>> usage
> > > >> >> >>> >>>> > section. I'd be in favor
of using --fetch for the
> > > >>RETRIEVAL
> > > >> >>of
> > > >> >> >>> >>>>plugins,
> > > >> >> >>> >>>> > --remove for the removal
of plugins from the local
> > plugins
> > > >> >> >>>cache,
> > > >> >> >>> >>>>and
> > > >> >> >>> >>>> > --install and --uninstall
for the relevant actions.
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>> > Max, re (2): correct.
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>> > To Braden's points:
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>> > - I'm fine with url +
name attributes for <dependency>
> > > >> >> >>>elements.
> > > >> >> >>> >>>>Will
> > > >> >> >>> >>>> > update the spec/README
shortly.
> > > >> >> >>> >>>> > - Re <clobbers>
I will add a note about that to the
> spec
> > > >>as
> > > >> >> >>>well.
> > > >> >> >>> >>>> > - Re parsing package Ids,
fair enough.
> > > >> >> >>> >>>> > - About "namespacing"
iOS source files, this sounds
> > like a
> > > >> >>good
> > > >> >> >>> >>>>idea.
> > > >> >> >>> >>>> > This is something that
plugman can handle as well,
> yes?
> > > >>That
> > > >> >>is,
> > > >> >> >>> >>>> > management of the plist
and pointing to the right
> > > >>location.
> > > >> >> >>> >>>> > - Re config munging and
permissions. I vote in favor
> of
> > > >> >> >>>removing
> > > >> >> >>> >>>>all
> > > >> >> >>> >>>> > permissions and re-adding
all of them with every
> change
> > in
> > > >> >> >>>plugins
> > > >> >> >>> >>>>(add
> > > >> >> >>> >>>> or
> > > >> >> >>> >>>> > remove), with a de-duping
pass. Brute force approach
> but
> > > >> >>it'll
> > > >> >> >>>work
> > > >> >> >>> >>>>and
> > > >> >> >>> >>>> is
> > > >> >> >>> >>>> > simple. However spec wise
we need a separate element
> for
> > > >>this
> > > >> >> >>>ya?
> > > >> >> >>> >>>> > <permission> or
something? Then based on what
> <platform>
> > > >>tag
> > > >> >> >>>houses
> > > >> >> >>> >>>>a
> > > >> >> >>> >>>> > <permissions> tag
we can deduce where and how to set
> up
> > > >>the
> > > >> >> >>> >>>>appropriate
> > > >> >> >>> >>>> > native permissions.
> > > >> >> >>> >>>> > - Re the different <*-file>
elements. I believe
> behavior
> > > >>in
> > > >> >>how
> > > >> >> >>> >>>>header
> > > >> >> >>> >>>> > and source files are handled
on iOS are identical, so
> > > >> >> >>>consolidating
> > > >> >> >>> >>>>those
> > > >> >> >>> >>>> > is an easy simplification.
I will update the spec with
> > > >>that.
> > > >> >> >>>I'll
> > > >> >> >>> >>>>leave
> > > >> >> >>> >>>> > resource-file in there
for now.
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>> > One more question that
came up: does a plugman
> --install
> > > >>call
> > > >> >> >>> >>>>implicitly
> > > >> >> >>> >>>> > call plugman --prepare
?
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>> > On 4/17/13 9:31 AM, "Max
Woghiren" <maxw@chromium.org
> >
> > > >> wrote:
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>> > >(1) On line 25 of
the cordova-plugman readme, is the
> > > >>command
> > > >> >> >>> >>>>missing
> > > >> >> >>> >>>> (ie.
> > > >> >> >>> >>>> > >--add or --install
or whatever)?
> > > >> >> >>> >>>> > >
> > > >> >> >>> >>>> > >(2) Though two versions
of a plugin are not allowed,
> I
> > > >>just
> > > >> >> >>>want to
> > > >> >> >>> >>>>make
> > > >> >> >>> >>>> > >sure: there will be
some kind of detection that it's
> > > >>okay if
> > > >> >> >>>the
> > > >> >> >>> >>>> > >*same*version of a
plugin has already been installed
> > by a
> > > >> >> >>>previous
> > > >> >> >>> >>>> > >dependency,
> > > >> >> >>> >>>> > >right? (For example,
plugins A and B both depend on C
> > > >>v1.0,
> > > >> >>so
> > > >> >> >>> >>>>plugman
> > > >> >> >>> >>>> > >will determine that
this is okay, whereas if A
> depends
> > > >>on C
> > > >> >> >>>v1.0
> > > >> >> >>> >>>>and
> > > >> >> >>> >>>>B
> > > >> >> >>> >>>> > >depends on C v1.1,
there'll be an error).
> > > >> >> >>> >>>> > >
> > > >> >> >>> >>>> > >
> > > >> >> >>> >>>> > >On Wed, Apr 17, 2013
at 3:08 AM, Filip Maj
> > > >><fil@adobe.com>
> > > >> >> >>>wrote:
> > > >> >> >>> >>>> > >
> > > >> >> >>> >>>> > >> Hey all,
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> I've done a review
of the spec and updated it.
> Check
> > it
> > > >> >>out
> > > >> >> >>>at
> > > >> >> >>> >>>>the
> > > >> >> >>> >>>> > >>README
> > > >> >> >>> >>>> > >> in the plugman
repo's future branch [1]. I've added
> > the
> > > >> >>last
> > > >> >> >>>bit
> > > >> >> >>> >>>>to
> > > >> >> >>> >>>> it:
> > > >> >> >>> >>>> > >> <dependencies>
and <dependency> elements. Here is
> an
> > > >> >>example:
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> <dependencies>
> > > >> >> >>> >>>> > >> <dependency
> > > >> >> >>> >>>> > >>
> > > >> >> >>>url="http://plugins.cordova.io/com.facebook.plugin/plugin.xml
> "
> > > >> >> >>> />
> > > >> >> >>> >>>> > >> <dependency
> > > >> >> >>> >>>> > >>
> > > >> >> >>>url="
> http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"
> > > >> >> >>> >>>> > >> version="1.0.0"
/>
> > > >> >> >>> >>>> > >> </dependencies>
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> Dependencies
are specified by providing a url and
> > > >> >>optionally
> > > >> >> >>>some
> > > >> >> >>> >>>>way
> > > >> >> >>> >>>> of
> > > >> >> >>> >>>> > >> describing what
version of the plugin you want. The
> > > >>only
> > > >> >> >>> >>>>constraint
> > > >> >> >>> >>>> > >> imposed on plugin
dependencies right now is only a
> > > >>single
> > > >> >> >>>version
> > > >> >> >>> >>>>of a
> > > >> >> >>> >>>> > >> plugin can be
installed in an app at the same
> time. I
> > > >> >>think
> > > >> >> >>>this
> > > >> >> >>> >>>>is
> > > >> >> >>> >>>> good
> > > >> >> >>> >>>> > >> enough, but wanted
to let everyone know and give
> > people
> > > >> >>time
> > > >> >> >>>to
> > > >> >> >>> >>>> comment.
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> Also did a bunch
of updates/tweaks to the
> plugin.xml
> > > >>spec,
> > > >> >> >>>made
> > > >> >> >>> >>>> explicit
> > > >> >> >>> >>>> > >> some failures
(if there are file conflicts, error
> > > >>noisily,
> > > >> >> >>>that
> > > >> >> >>> >>>>kind
> > > >> >> >>> >>>> of
> > > >> >> >>> >>>> > >> stuff). I have
a PluginTooling [2] wiki article up
> > > >>where
> > > >> >>I am
> > > >> >> >>> >>>>doing my
> > > >> >> >>> >>>> > >> best to summarize
these various reqs/use cases
> > floating
> > > >> >> >>>around
> > > >> >> >>> >>>>the
> > > >> >> >>> >>>> list,
> > > >> >> >>> >>>> > >> IRC, hangout
discussions regarding plugin tooling
> > > >> >> >>>development. If
> > > >> >> >>> >>>>you
> > > >> >> >>> >>>> > >>have
> > > >> >> >>> >>>> > >> anything to add
there please do so!
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> Next, I have
a few questions came up when I was
> going
> > > >> >>through
> > > >> >> >>>the
> > > >> >> >>> >>>> spec:
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> - does <clobbers>
and <merges> (specified in the JS
> > > >>symbol
> > > >> >> >>> >>>>mapping
> > > >> >> >>> >>>> > >> section of the
plugin spec) create the objects on
> > > >>window
> > > >> >>if
> > > >> >> >>>they
> > > >> >> >>> >>>>do
> > > >> >> >>> >>>> not
> > > >> >> >>> >>>> > >> exist? I suppose
this is more of a cordova.js
> > question
> > > >> >>than a
> > > >> >> >>> >>>>spec
> > > >> >> >>> >>>> > >> question, but
that behavior should be explicit in
> the
> > > >> >>spec.
> > > >> >> >>> >>>> > >> - native code
<source-file> elements have a
> `target`
> > > >> >> >>>attribute
> > > >> >> >>> >>>>where
> > > >> >> >>> >>>> > >>you
> > > >> >> >>> >>>> > >> specify where
within the native project the native
> > code
> > > >> >> >>>should be
> > > >> >> >>> >>>> copied
> > > >> >> >>> >>>> > >> into. Is this
necessary? For Java files, we could
> > look
> > > >>at
> > > >> >>the
> > > >> >> >>> >>>>package
> > > >> >> >>> >>>> > >> declaration at
the top to determine where to put
> it.
> > If
> > > >> >>I'm
> > > >> >> >>>not
> > > >> >> >>> >>>> > >>mistaken,
> > > >> >> >>> >>>> > >> on iOS it doesn't
matter where within the directory
> > > >> >>structure
> > > >> >> >>>of
> > > >> >> >>> >>>>a
> > > >> >> >>> >>>> > >> cordova-ios project
you put native code in. What is
> > the
> > > >> >> >>>situation
> > > >> >> >>> >>>>for
> > > >> >> >>> >>>> > >>the
> > > >> >> >>> >>>> > >> Windows (Phone)
platforms, and for cordova-osx?
> > > >> >> >>> >>>> > >> - the spec currently
only accounts for appending
> XML
> > to
> > > >> >> >>>specific
> > > >> >> >>> >>>> parts
> > > >> >> >>> >>>> > >>of
> > > >> >> >>> >>>> > >> XML-based configuration
documents. Does anyone
> > foresee
> > > >>an
> > > >> >> >>> >>>>instance
> > > >> >> >>> >>>> where
> > > >> >> >>> >>>> > >> some manner of
native or cordova-specific config
> > > >>munging
> > > >> >> >>>OTHER
> > > >> >> >>> >>>>than
> > > >> >> >>> >>>> > >> appending would
be necessary? Removal/modification
> of
> > > >> >> >>>existing
> > > >> >> >>> >>>> elements?
> > > >> >> >>> >>>> > >> - iOS specific:
Do we need separate elements for
> > > >> >> >>><source-file>,
> > > >> >> >>> >>>> > >> <resource-file>
and <header-file>? Can we
> consolidate
> > > >>into
> > > >> >> >>>one?
> > > >> >> >>> >>>>The
> > > >> >> >>> >>>> > >> current draft
of the spec mentions that this may be
> > an
> > > >> >> >>> >>>>implementation
> > > >> >> >>> >>>> > >> detail.
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> Finally, I have
two questions/concerns about the
> > > >>command
> > > >> >>line
> > > >> >> >>> >>>> interface
> > > >> >> >>> >>>> > >> for plugman.
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> 1. The --fetch
operation seems to need a redundant
> > > >> >>--plugin
> > > >> >> >>>flag,
> > > >> >> >>> >>>>e.g.
> > > >> >> >>> >>>> > >> plugman --fetch
--plugin <url>. Shouldn't we just
> axe
> > > >> >> >>>--plugin in
> > > >> >> >>> >>>>this
> > > >> >> >>> >>>> > >> case?
> > > >> >> >>> >>>> > >> 2. The API readme
mentions --install and
> --uninstall
> > > >>flags
> > > >> >> >>>but
> > > >> >> >>> >>>>the
> > > >> >> >>> >>>> docs
> > > >> >> >>> >>>> > >> only show --fetch
and --remove. Can we clarify
> this?
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> Thanks for everyone's
input. I feel we're getting
> > > >>closer
> > > >> >>to
> > > >> >> >>> >>>>shipping
> > > >> >> >>> >>>> > >>this
> > > >> >> >>> >>>> > >> thing!
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >> [1]
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>>
> > > >> >> >>> >>>>
> > > >> >> >>>
> > > >> >>
> > > >>
> > https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlo
> > > >> >> >>> >>>>g
> > > >> >> >>> >>>> > ;
> > > >> >> >>> >>>> > >>h=
> > > >> >> >>> >>>> > >> refs/heads/future
> > > >> >> >>> >>>> > >> [2] http://wiki.apache.org/cordova/PluginTooling
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> > >>
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>> >
> > > >> >> >>> >>>>
> > > >> >> >>> >>
> > > >> >> >>> >
> > > >> >> >>> >
> > > >> >> >>>
> > > >>
> > >>>---------------------------------------------------------------------
> > > >> >> >>> >This transmission (including any attachments)
may contain
> > > >> >>confidential
> > > >> >> >>> >information, privileged material (including
material
> protected
> > > >>by
> > > >> >>the
> > > >> >> >>> >solicitor-client or other applicable privileges),
or
> > constitute
> > > >> >> >>> >non-public information. Any use of this
information by
> anyone
> > > >>other
> > > >> >> >>>than
> > > >> >> >>> >the intended recipient is prohibited. If
you have received
> > this
> > > >> >> >>> >transmission in error, please immediately
reply to the
> sender
> > > >>and
> > > >> >> >>>delete
> > > >> >> >>> >this information from your system. Use,
dissemination,
> > > >> >>distribution,
> > > >> >> >>>or
> > > >> >> >>> >reproduction of this transmission by unintended
recipients
> is
> > > >>not
> > > >> >> >>> >authorized and may be unlawful.
> > > >> >> >>>
> > > >> >> >>>
> > > >> >> >
> > > >> >> >
> > > >> >>
> > >
> >>>---------------------------------------------------------------------
> > > >> >> >This transmission (including any attachments) may contain
> > > >>confidential
> > > >> >> >information, privileged material (including material
protected
> by
> > > >>the
> > > >> >> >solicitor-client or other applicable privileges), or
constitute
> > > >> >> >non-public information. Any use of this information by
anyone
> > other
> > > >> >>than
> > > >> >> >the intended recipient is prohibited. If you have received
this
> > > >> >> >transmission in error, please immediately reply to the
sender
> and
> > > >> >>delete
> > > >> >> >this information from your system. Use, dissemination,
> > > >>distribution, or
> > > >> >> >reproduction of this transmission by unintended recipients
is
> not
> > > >> >> >authorized and may be unlawful.
> > > >> >>
> > > >> >>
> > > >> >>
> > ---------------------------------------------------------------------
> > > >> >> This transmission (including any attachments) may contain
> > > >>confidential
> > > >> >> information, privileged material (including material protected
by
> > the
> > > >> >> solicitor-client or other applicable privileges), or constitute
> > > >> >>non-public
> > > >> >> information. Any use of this information by anyone other
than the
> > > >> >>intended
> > > >> >> recipient is prohibited. If you have received this transmission
> in
> > > >> >>error,
> > > >> >> please immediately reply to the sender and delete this
> information
> > > >>from
> > > >> >> your system. Use, dissemination, distribution, or reproduction
of
> > > >>this
> > > >> >> transmission by unintended recipients is not authorized and
may
> be
> > > >> >>unlawful.
> > > >> >>
> > > >>
> > > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message