downloading windows 7 now... I haven't writ code for windows since 2000 was new!
*shudders* On Thu, Feb 9, 2012 at 11:42 AM, Filip Maj <[email protected]> wrote: > I'll do the same and work on a patch. I'll post links to patch source so > we can collaborate on getting this done, Jesse/Gord. I'll aim for next > week, and Jesse we can sync up in person. > > On 12-02-09 7:45 PM, "[email protected]" <[email protected]> wrote: > >>I am setting up a windows dev environment. >> >>I was a c# dev in a past life so I can see if I can step up on wp7 too. >> >> >>Sent on the TELUS Mobility network with BlackBerry >> >>-----Original Message----- >>From: Jesse <[email protected]> >>Date: Thu, 9 Feb 2012 10:35:15 >>To: <[email protected]> >>Reply-To: [email protected] >>Subject: Re: Work Items for 1.5.0 - unified JS >> >>Re: shipping date. >>I can say with almost absolute uncertainty that I alone will not get this >>into WP7 for 1.5 release at the end of the month. >> >>On Thu, Feb 9, 2012 at 9:48 AM, Patrick Mueller <[email protected]> wrote: >> >>> On Thu, Feb 9, 2012 at 12:07, Filip Maj <[email protected]> wrote: >>> >>> > Three parts to this email. First: >>> > >>> > >[ Whole bunch of discussion] >>> > > >>> > >Perhaps it's time to define "AMD-lite" runtime somewhere? >>> > >>> > ^^ Pretty much. >>> > >>> > In my mind the simplest way to distill the discussion down is: do we >>>want >>> > to employ almond or some other AMD+CJS-compliant loaders, and make it >>> > obvious to users that this comes with cordova, or roll our amdlite or >>>smd >>> > or whatever you want to call it, a cut-down version tailored for our >>> > needs, and hide the fact we use it (closure that stuff up)? >>> > >>> >>> If we closure it up, we don't need to say anything about >>>AMD/AMD-lite/SMD. >>> If we have a version that we don't closure up, we do neede to talk >>>about >>> the AMD-ish API. Easiest path is to closure it up, I guess. I might >>>press >>> for an option on the build script, which we wouldn't use for the >>>production >>> cordova.js, to allow for other options: >>> >>> - don't closure it up >>> - don't closure it up, and don't prepend our AMD-ish runtime, allowing >>> someone else to prepend theirs (eg, require.js, Dojo, etc) >>> >>> >>> > Second: >>> > >>> > One thing Mike and I chatted about today was the various platform >>> > definition files ... It used a >>> > JSON convention that currently is something like: >>> > >>> > [[icky crap elided]] >>> > >>> > ... One convention that could be employed is >>> > having a string value instead of an object if it's a module path alone >>> (no >>> > children). Mike took it a different route and was thinking of >>>something >>> > string-based like: >>> > >>> > { >>> > "window.PhoneGap":"lib/phonegap", >>> > "window.PhoneGap.exec":"lib/phonegap/exec" >>> > } >>> > >>> >>> This was the sort of thing I was thinking about. Rather than object >>> structures, we can use strings with path structures ("." or "/" or >>>whatever >>> delimited). >>> >>> >>> > Third: >>> > >>> > I really want to ship cordova-js for 1.5. There is a lot that can be >>> > improved, but I'm hoping that improvements can be slowly introduced >>>over >>> > the next few releases. I am hoping that none of the issues that you >>> > brought up, Pat, are "show-stoppers". >>> > >>> >>> +1 on shipping a "built from modules" cordova.js for 1.5. Anyway we >>>can do >>> that. It's a step in the right direction. Some implementation choices >>> imply (in my mind) show-stoppers, like shipping almond 0.3 - so we don't >>> use those implementation choices. >>> >>> -- >>> Patrick Mueller >>> http://muellerware.org >>> >> >
