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 tooling/specification
Date Sun, 16 Sep 2012 14:51:53 GMT
Hey Andrew,

I have some questions/thoughts on pluginstall and it's related spec that
I'd like to run by you (and anyone else here that feels they have insight
to add.)

I noticed that the source and destination are explicitly specified (e.g.,
copy src/android/ChildBrowser.java to src/com/phonegap/plugins/childBrowser

It seems to me that there are 2 ways this could be done. The current way
(explicitly specify where a file is copied from/to) and also an implicit
structure, where the structure of the plugin's directory layout would
automatically determine where it goes in the destination app. I think both
approaches have some pros and cons. The explicit copying is more flexible
because you have a lot more power over where to put files. It also doesn't
require modification to an existing plugin's source code; you can simply
build a plugin manifest file, wrap it up, and bam! you've got a workable
plugin archive. The downside to this appproach is there's not namespacing
of plugins, and increases the likelihood of native/www asset collisions. It
also means the plugin manifest is a bit more verbose.

My thoughts are, given how few plugins are really supported in an automated
fashion, it may make sense to revisit the expected structure of plugins and
make changes to prepare for a likely future where cordova plugin
installation is similar to npm; lots of packages installable in an
automated way. Now seems like a really good time to prepare for this given
how few people are probably using this tool manually, and given that it's
likely to increase in adoption. What are your thoughts on this idea of
auto-namespacing plugins and removing some of the explicit file pathing
stuff? I looked at childbrowser and pgsqlite as the only 2 working examples
of this plugin manifest and don't see why it coudln't work, but I didnt
want to just jump in an start re-architecting this tool without getting
your feedback because you've spent time in the trenches making this work in
a production environment.


By the way, for anyone else that has read this far, is this still the right
place for this discussion, or is this too in-depth, and belonging in a JIRA
ticket or some other place? I hate the idea of slamming the general dev
list with questions and traffic not relevant to a large portion of the
contributors.


-Mike


On Sat, Sep 15, 2012 at 10:47 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> Right. In that case, we could make those cordova command tools slightly
> smarter ;)
>
> On Sat, Sep 15, 2012 at 7:29 PM, Filip Maj <fil@adobe.com> wrote:
>
> > Right. I'm ok with this but wanted to keep the exact cordova-powered
> > platform projects as untouched as possible, so you could cd into those
> > directories and do whatever you want (run usual cordova project commands,
> > compile, etc). So removing the www from there forces everyone to always
> go
> > through the tool.
> >
> > On 9/15/12 7:23 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
> >
> > >On Sat, Sep 15, 2012 at 5:32 PM, Filip Maj <fil@adobe.com> wrote:
> > >
> > >>
> > >> >Ohhh I think I understand. So basically it packages the www resources
> > >>into
> > >> >the binary at build time?
> > >>
> > >> Correct. Each platform's underlying implementation has its own "www"
> > >> folder. At build time, the top-level www of your project gets copied
> > >>into
> > >> each platform before doing a compile for that platform.
> > >>
> > >> >> platforms/xxx/www gets destroyed and recreated on every build.
See
> > >> >> here<http://bit.ly/PFKQvS>.
> > >> >> It's needed to build packages for every platform. It could arguably
> > >>be
> > >> >> destroyed after every build though. Fil is there a reason why
> that's
> > >>not
> > >> >> the case ?
> > >>
> > >> That is the case is it not? Line 57?
> > >>
> > >> Or do you mean, we should delete the platforms/<platform>/www (or
> > >> equivalent) after building?
> > >>
> > >
> > >Yes that's what I meant.
> > >
> > >
> > >>
> > >> If the latter, I don't see the point.
> > >>
> > >
> > >To avoid confusion. The reason why we're discussing this is because Mike
> > >got confused after seeing the root www and a www in each platform
> > >subfolder. There is also no reason to keep them around since they get
> > >destroyed before every build anyway. So maybe they should just get
> > >destroyed _after_ every build. You'd just recursively copy the folder
> > >before every build. I don't really care either way. Just trying to avoid
> > >the "Where do I drop my code?" scenario.
> >
> >
>

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