...and the BlackBerry guys! :)
On Wed, Feb 27, 2013 at 4:37 PM, Jeffrey Heifetz <[email protected]> wrote: > Actually I'm lucky enough to be heading down to join in on the fun, > looking forward to meeting all of you. > > On 2013-02-27, at 6:26 PM, Al Harding wrote: > > > 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 > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> > >>> > >> > > > --------------------------------------------------------------------- > 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. >
