I'm all for this, I'd love to see this merged, way less of a hack and far bigger upside than using the url for transport. This is much closer to the Android implementation and, if ever iOS gets backgrounding some very cool possabilities open up. I'm curious, what is the licensing ramifications of this change?
On Wed, Oct 26, 2011 at 1:42 PM, Matthew Schulkind <[email protected]> wrote: > Another huge benefit of this that I forgot to mention is that this allows > for running JS on a non-GUI thread, so you can run calculations, etc. > without blocking the UI, but it's definitely going to be tricky to take full > advantage of this. > > On Wed, Oct 26, 2011 at 4:38 PM, Matthew Schulkind > <[email protected]>wrote: > >> Here's what I've done to phonegap: >> https://github.com/mschulkind/phonegap-iphone/tree/spidermonkey >> >> I'm using iMonkey for the SpiderMonkey port: >> https://github.com/couchbaselabs/iMonkey >> Right now, I can only get iMonkey working on the device, not the simulator, >> but I'm sure it's possible with some work. It just crashes without a good >> stack trace on the simulator. >> >> Here's the glue code that I've written so far: >> https://github.com/mschulkind/sm-bridge >> It would take a little work to integrate this into your own stuff, but >> should give you a pretty good idea of what's going on. >> >> SpiderMonkey is purely a JS environment, so it doesn't have DOM etc. and >> you'll see that I rewrote the Interval/Timeout stuff as well as some event >> stuff, and I had to write an HTTP plugin since there's no XHR built in >> either. >> >> All that said, the main challenge for using this for Callback in general is >> that there's no HTML type display, and the only HTML display that Apple >> allows is UIWebView, so I'm not sure how you'd use this on a Callback >> project that does the typical HTML5/CSS approach. >> >> >> On Wed, Oct 26, 2011 at 4:27 PM, Brian LeRoux <[email protected]>wrote: >> >>> Matthew --- this is really interesting work. Where can I have a look >>> at your Spidermonkey stuff? Think its a very compelling route. >>> >>> >>> >>> On Wed, Oct 26, 2011 at 9:53 AM, Matthew Schulkind <[email protected]> >>> wrote: >>> > I've now run just about all of my code (including phonegap) under V8 >>> (using >>> > chrome for the developer tools), WebKit, and now SpiderMonkey with no >>> > changes other than adding the missing bits where appropriate (like >>> > setTimeout/Interval and XHR for SpiderMonkey). >>> > >>> > What problems would you think would exist? >>> > >>> > On Wed, Oct 26, 2011 at 12:46 PM, Matt Kane <[email protected]> wrote: >>> > >>> >> I meant in general, rather than specific to the ObjC<->JS bridge. >>> >> >>> >> On 26 Oct 2011, at 17:36, Matthew Schulkind wrote: >>> >> >>> >> > I was using only UIWebView and had the previously mentioned problems. >>> Now >>> >> I >>> >> > ripped out UIWebView completely and I'm only using SpiderMonkey and >>> >> having >>> >> > none of the previously mentioned problems. >>> >> > >>> >> > On Wed, Oct 26, 2011 at 4:14 AM, Matt Kane <[email protected]> >>> wrote: >>> >> > >>> >> >> You're using Webkit + Spidermonkey? Isn't that just asking for >>> massive >>> >> >> compatibility headaches? >>> >> >> >>> >> >> On 25 Oct 2011, at 23:29, Matthew Schulkind wrote: >>> >> >> >>> >> >>> I have had tons of problems with UIWebView in general, so much so >>> that >>> >> >> I've >>> >> >>> just about finished abandoning it. I've been working on a set of >>> native >>> >> >> UI >>> >> >>> components for Callback (that sounds weird...), so I luckily don't >>> need >>> >> >> the >>> >> >>> HTML display of UIWebView, so I'm currently 90% of the way to >>> >> integrating >>> >> >>> SpiderMonkey with phonegap, which totally gets rid of any exec() >>> type >>> >> >>> problems because you get to use a real ObjC<->Javascript interface. >>> >> >> >>> >> >> >>> >> >>> >> >>> > >>> >> >> >
