incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: plugin analysis
Date Tue, 02 Oct 2012 18:25:59 GMT
Hey Brian,

> engine attribute in package.json
Maybe I'm wrong but after reading  https://npmjs.org/doc/json.html I'm
under the impression this is solely for specifying the required version(s)
of node to use the npm package.

> I do not understand the problem
The problem is before allowing someone to register a plugin, we want to
perform certain checks on the server side that prevent things from blowing
up or corrupting the repo. One very easy thing to check is that the package
identifier a plugin author declares is not collding. I should not be able
to package com.alunny.foo if it's already used by another package.

> (Lets not solve ones we do not yet have yet
I agree that we should not try to predict every problem that could come up
and solve it up front. I also think that some issues have a nice balance
between being able to check, and being easy to do that them worth doing.
Simple things like verifying plugin.xml is a valid xml doc, that package
names dont collide, etc are very easy to do, and are important to repo
integrity.




On Tue, Oct 2, 2012 at 2:13 PM, Brian LeRoux <b@brian.io> wrote:

> >    - Cordova plugins depend on specific versions of the cordova library,
> >    and specific versions of xcode, android build tools, and other SDKs.
>  npm
> >    doesnt provide a way to declare those external plugin dependencies, or
> >    query by them.
>
> Sure it does. engine attribute in package.json (but will require a
> custom couch view which can be authored rather quickly).
>
> >    - one thing that would really be helpful in the future is to have the
> >    ability to set up rules at the repo publishing point. For example,
> >    preventing someone from publishing a new plugin that re-uses and
> existing
> >    package name (com.alunny.foo) and doing basic sanity checks that are
> >    specific to our plugin format. Using npm makes this a lot harder.
>
> I do not understand the problem but I'm certain once there is code we
> could implement a solution. (Lets not solve ones we do not yet have
> too much!)
>
> >    - npm is intended as a dev tool and package manager for node based
> >    apps/libs. We'd be overloading it's intended behavior by throwing in a
> >    bunch of plugins that are relevant only to the Cordova platform.
>
> ya its cool, I've talked to the node guys about it. we'll likely run a
> separate federated registry in the future. in issac's own words, 'npm
> is a commons for js'
>
>
> >    Having a little discovery portal like npmjs.org that is
> >    specific to our community would be huge.
>
> thats the vision breaux
>

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