Awesome! We've got a room booked at Adobe SF with projector, camera, beer, so we can loop anyone in who is remote.
Look forward to meeting the Google guys! -Al On Wed, Feb 27, 2013 at 2:44 PM, Michal Mocny <[email protected]> wrote: > Oh sweet, we were just saying how we still haven't met most of you. > > Sadly, Braden is not coming on this trip, but Andrew, Max and I will be > there (and working from Adobe Friday) we will have time to chat. Can bring > Braden in via Hangout. > > -Michal > > > On Wed, Feb 27, 2013 at 5:40 PM, Filip Maj <[email protected]> wrote: > > > Yep! There's an online code review planned for March 22nd for both the > cli > > tools as well as the plugman tool. > > > > Also: next week most Adobe cordova folk will be in SF, and so will you > > Googlers ya? We can talk specifics and hash out our ideas better then and > > bring it back to the list. > > > > On 2/27/13 2:26 PM, "Michal Mocny" <[email protected]> wrote: > > > > >I think we have a hangout scheduled for that conversation (among others) > > >right? Its good that Braden is setting up topics of conversation :) > > > > > >-Michal > > > > > > > > >On Wed, Feb 27, 2013 at 4:37 PM, Filip Maj <[email protected]> wrote: > > > > > >> I think this is a good conversation to have. > > >> > > >> Note that, if we do split up how plugins are treated and when we copy > > >> files around (I.e. Move the www assets on every prepare, but the > native > > >> files only on platform/plugin adds), then the plugman tool will either > > >> need finer-grained support for these types of actions or we need to > > >> assimilate/couple the plugman code closer to cordova-cli. > > >> > > >> On 2/27/13 1:32 PM, "Braden Shepherdson" <[email protected]> wrote: > > >> > > >> >I'm on the fence about native plugin code. I think iOS has some > > >> >complications there. > > >> > > > >> >Over the course of my work on the installation prototype, I've > actually > > >> >moved to copying plugin www files on every prepare, that works great. > > >> > > > >> >For native code, I wonder if that's best done on add/remove. I was > > >>mostly > > >> >thinking about www files for the original proposal. > > >> > > > >> >Braden > > >> > > > >> > > > >> >On Wed, Feb 27, 2013 at 4:24 PM, Filip Maj <[email protected]> wrote: > > >> > > > >> >> Couple notes before I add some comments: > > >> >> > > >> >> - in general plugin add and rm is COMPLETELY delegated to the > plugman > > >> >> tool. See [1]. Most of the code linked is error checking, otherwise > > >>it > > >> >> shells out to plugman.. With one exception.. > > >> >> - what happens in [2]. Which is the point Braden brought up about > > >> >> polluting the user's www. Totally agree this should change. At the > > >>time > > >> >>of > > >> >> writing that I dropped a TODO [3] that this was a likely bad > > >>assumption. > > >> >> - the "what plugins are installed" code is already a `ls plugins/` > > >>run > > >> >>[4]. > > >> >> > > >> >> Now going back to your proposal: > > >> >> > > >> >> 1. Never pollute user's www. I completely agree with this. Time to > > >> >> refactor that out. > > >> >> 2. Use existence of directories under the ./plugins dir to identify > > >> >>which > > >> >> plugins are installed. Yep. Already does that as shown in [4]. > > >> >> > > >> >> If I understand correctly, you are proposing we run a plugin > > >> >>installation > > >> >> (I.e. Copy over appropriate files and edit config files) every time > > >> >> cordova prepare is run. This would mean that every time we run > > >>prepare, > > >> >>we > > >> >> have to recreate a native cordova project (otherwise we'd be > > >>installing > > >> >> plugin files into the native project on every command). I'm not > sure > > >>I > > >> >> agree with this.. I have to think more about it.. > > >> >> > > >> >> I think this conversation boils down to: should we be recreating > > >>cordova > > >> >> projects on every command, or keep the native projects "persistent" > > >> >>across > > >> >> commands (which is currently how it operates). > > >> >> > > >> >> [1] > > >>https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L72 > > >> >> [2] > > >> https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L116 > > >> >> [3] > > >> >> > > >> >> > > >> > > >> > > > https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L117-L118 > > >> >> [4] > > >> >> > > >> > https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L51-L52 > > >> >> > > >> >> On 2/25/13 8:24 AM, "Michal Mocny" <[email protected]> wrote: > > >> >> > > >> >> >Just to clarify this in my head: > > >> >> > > > >> >> >* Since we have a prepare step now, you propose moving some of the > > >> >>logic > > >> >> >that used to run on plugin add out into the prepare step. That > > >>sounds > > >> >> >good. > > >> >> >* You want to fix how we track which plugins are installed by > going > > >>to > > >> >> >source instead of some config file. That sounds good. > > >> >> >* You want to fix a bunch of stuff with the prepare step > (including > > >>the > > >> >> >current add logic). I can't really comment on specifics here, > but I > > >> >>guess > > >> >> >this is not as radical of a change as I thought on first pass. > > >> >> > > > >> >> >I briefly asked you offline but wanted to bring it into the ML: > How > > >> >>does > > >> >> >this proposal affect our current plan for plugin upgrading? (Your > > >> >>answer, > > >> >> >paraphrasing, was that prepare step should ideally be stateless > and > > >> >>start > > >> >> >from any clean state. Thus, upgrade is simply an rm & add & > > >>prepare) > > >> >> > > > >> >> >-Michal > > >> >> > > > >> >> > > > >> >> >On Mon, Feb 25, 2013 at 10:32 AM, Braden Shepherdson > > >> >> ><[email protected]>wrote: > > >> >> > > > >> >> >> I'm running into several problems with the current > implementation > > >>of > > >> >> >> cordova-cli: > > >> >> >> > > >> >> >> * There's no single source of truth for what plugins are > > >>installed. > > >> >>It > > >> >> >>uses > > >> >> >> the presence of a plugin's name in the www/config.xml currently. > > >>This > > >> >> >> doesn't work for JS-only plugins, and there are some, especially > > >>on > > >> >> >>other > > >> >> >> platforms. > > >> >> >> * It's polluting (maybe clobbering!) the user's www/ during > plugin > > >> >>add. > > >> >> >> * It expects plugins to have a www/ directory it copies whole > into > > >> >>the > > >> >> >> top-level www/, rather than honouring <asset> tags as per docs. > > >> >> >> > > >> >> >> My proposal is to rewire cordova-cli according to two > principles: > > >> >> >> > > >> >> >> 1. We never pollute the user's www/ with anything. Full stop. > > >> >> >>Everything we > > >> >> >> do automagically goes into the platform directories at cordova > > >> >>prepare > > >> >> >> time. > > >> >> >> 2. We use the existence of absence of directories in plugins/ as > > >>the > > >> >> >>source > > >> >> >> of truth for what is or isn't installed. > > >> >> >> > > >> >> >> Under this model, plugin add/rm become fancy aliases for cp -R > > >>and rm > > >> >> >>-rf. > > >> >> >> No magic or copying of JS or native files or config editing or > > >> >>anything > > >> >> >> else happens on plugin add: We just copy the directory into > > >>plugins/. > > >> >> >> > > >> >> >> Then on cordova prepare, we copy native files into the > platforms, > > >> >>edit > > >> >> >> platform-specific config files to include <plugin> tags and > > >> >>permissions > > >> >> >>and > > >> >> >> list the native files. > > >> >> >> > > >> >> >> iOS makes this hard, since it has a project file that lists all > > >> >>native > > >> >> >> files in the project. We can get around this by putting all > plugin > > >> >>files > > >> >> >> into a subdirectory like src/plugins. Then on cordova prepare we > > >>can > > >> >>get > > >> >> >> every file in that directory, remove them from the project file, > > >> >>delete > > >> >> >> them, then copy every plugin's native files and add them to the > > >> >>project > > >> >> >> file. Then the project file always matches the current load of > > >> >>plugins. > > >> >> >> > > >> >> >> I'm volunteering to do the work required for this. I just want > to > > >>run > > >> >> >>the > > >> >> >> idea past people before I start fundamentally changing how the > > >>tool > > >> >> >>works. > > >> >> >> I think this will make many parts of the code simpler to read > and > > >> >> >>document, > > >> >> >> and make the behavior of the tool much clearer and less magical > to > > >> >> >>users. > > >> >> >> > > >> >> >> Braden > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > >
