Here's the hangout link! https://plus.google.com/hangouts/_/d769196db4691ea063c6787c6d660719e021e594 ?authuser=0&hl=en
On 3/7/13 11:21 AM, "Jesse" <[email protected]> wrote: >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
