Do we have a time set for this? I won't be able to attend in person, but I will be in the hangout.
Cheers, Jesse On Wed, Feb 27, 2013 at 4:42 PM, Al Harding <[email protected]> wrote: > ...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. > > > -- @purplecabbage risingj.com
