cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Brainstorming Proposal: Implementing apps as plugins
Date Tue, 12 Feb 2013 19:59:52 GMT
+1 to moving plugman into CLI. I think the two tools will have more and
more overlap going forward.


On Tue, Feb 12, 2013 at 3:00 PM, Filip Maj <fil@adobe.com> wrote:

> This is correct Michal.
>
> Still not sure I like the fact that we are either a) creating a new
> manifest for applications that are at odds with config.xml or b) extending
> config.xml with our own shit.
>
> In the end the concern here is smart re-use of code (I.e. Hey, plugin
> installation is sort of like app management), yes? Why not code review the
> cordova-cli and plugman projects  and see which areas we could optimize +
> refactor to achieve this goal, instead of coming up with a new approach
> that requires new manifests? I've also been recommending we move the
> plugman code into cordova-cli for a while.
>
> On 2/12/13 11:37 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
>
> >Plugins can specify whole directories as well, so it would be trivial to
> >copy the whole www folder, I believe.
> >
> >
> >On Tue, Feb 12, 2013 at 2:31 PM, Braden Shepherdson
> ><braden@chromium.org>wrote:
> >
> >> Plugin devs are left to put together their own file structure. Plugins
> >>are
> >> pretty freeform, you specify where to find things with <asset> and
> >> <source-file> tags; the installed locations have nothing to do with the
> >> plugin repo locations.
> >>
> >> The main difference that I can see is that plugins specify every file
> >>they
> >> want copied where when installed, whereas apps just put things in www/.
> >>
> >> I'm leaning towards the correct approach here being to treat them as
> >> separate but share as much code as we can.
> >>
> >> Braden
> >>
> >>
> >> On Tue, Feb 12, 2013 at 2:08 PM, Michal Mocny <mmocny@chromium.org>
> >>wrote:
> >>
> >> > On Tue, Feb 12, 2013 at 1:48 PM, Filip Maj <fil@adobe.com> wrote:
> >> >
> >> > >
> >> > > >So, if an app was bundled as a plugin with its www folder, then
if
> >>it
> >> > > >could
> >> > > >use config-file modification to set the startPage (this may not
be
> >> > > >supported yet), would that be enough?  Ideally plugins would
> >>support
> >> > > >importing a while config.xml file?
> >> > >
> >> > > I think so.. Currently config file modification in plugman only
> >> supports
> >> > > appending to a config document but that can be changed.
> >> > >
> >> > > >Also, there is obviously a bit of confusion with using the name
> >> "plugin"
> >> > > >for an "app".
> >> > >
> >> > > Yeah this is my biggest concern. With the current setup, it is clear
> >> > where
> >> > > the application goes. It is on its own and exists right from the get
> >> go -
> >> > > without any added platforms or plugins. While plugin.xml is nice in
> >> that
> >> > > it supports conditional platform config modification + assets, does
> >> this
> >> > > mean users will need to add a plugin.xml to their app before using
> >>it
> >> > with
> >> > > the tools? This all seems backwards. While I understand the
> >> functionality
> >> > > of both current and proposed approaches essentially DO the same,
> >>this
> >> > > doesn't mean we should dictate the user workflow to follow the
> >> > > implementation.
> >> > >
> >> >
> >> > Its true, the names are confusing and there are slight differences.
> >> >  Perhaps cordova-cli could support two types of manifests: config.xml
> >>(or
> >> > call it app.xml?) and plugin.xml.  Both apps and plugins could have
> >>the
> >> > same folder structure, and the manifests would mostly share a common
> >>set
> >> of
> >> > accepted tags/functionality.
> >> >
> >> > As for setup, then cordova-cli could have an "app-init" action and
> >> > "app-install".
> >> >
> >> > (side-question: do we have "plugin-init" cordova-cli command planned
> >>or
> >> do
> >> > we tell plugin devs to initialize the file structure manually?)
> >> >
> >> > -Michal
> >> >
> >>
>
>

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