On 7 juin, 02:24, Mark Renouf mark.ren...@gmail.com wrote:
If the WebSocket
standard ever materializes, it could be even better (and standards
based), and act as a last-resort fallback on all platforms.
WebSocket is all about async communications which is a show-stopper
for OOPHM. When I
On 7 juin, 02:13, Mark Renouf mark.ren...@gmail.com wrote:
On Jun 5, 12:49 pm, Piotr Jaroszyński p.jaroszyn...@gmail.com wrote:
Security-wise I think it can match the w3 spec - at least for GETs and
POSTs (other methods are not supported in GWT anyway because of the
safari bug). The
On 5 juin, 19:22, Bart Guijt bgu...@gmail.com wrote:
Cool!
I am specifically interested in the AppCache manifest linker, which
was also mentioned on one of the slides. Can *that* code be made
public too?
It shouldn't be that different from the Gears Offline linker you can
already find
On Sun, Jun 7, 2009 at 9:46 AM, Thomas Broyer t.bro...@gmail.com wrote:
On 7 juin, 02:24, Mark Renouf mark.ren...@gmail.com wrote:
If the WebSocket
standard ever materializes, it could be even better (and standards
based), and act as a last-resort fallback on all platforms.
WebSocket is
2009/6/7 John Tamplin j...@google.com:
On Sun, Jun 7, 2009 at 9:46 AM, Thomas Broyer t.bro...@gmail.com wrote:
On 7 juin, 02:24, Mark Renouf mark.ren...@gmail.com wrote:
If the WebSocket
standard ever materializes, it could be even better (and standards
based), and act as a last-resort
2009/6/7 Piotr Jaroszyński p.jaroszyn...@gmail.com
Can't you emulate sync calls with async calls in js? Locking would be
best but can't you always retract to busy looping?
You would then get constant slow script warnings.
--
John A. Tamplin
Software Engineer (GWT), Google
On 7-Jun-09, at 8:39 AM, John Tamplin wrote:
Yes, the very thing you want for real apps (async so you can drop
back to the event loop and let the browser respond while waiting on
IO) is the very thing you can't have for OOPHM, since you have to be
able to block the executing code in
On 6-Jun-09, at 6:24 PM, Mark Renouf wrote:
Wow, I like it! This isn't as crazy as it sounds. After just watching
the V8 talk from I/O, I've learned the JavaScript library is
implemented in JavaScript (preloaded in a heap snapshot).
The efficiency level they are hitting now makes this seem
On Sun, Jun 7, 2009 at 12:38 PM, Matt Mastracci matt...@mastracci.comwrote:
BTW, one advantage of this XPCOM version is that it would work on both
FF 3.0 and 3.5. The current OOPHM XPI fails on 3.5, as the Moz devs
changed some of the JS type constants. JSVAL_VOID (the effective
internal
Comment by foh1981:
As a complete newbie, this was kinda hard for me to setup on *Ubuntu 9.04
64-bit*. It sure didn't help being a newbie of all things Eclipse either :P
Anyway, what I did was to build GWT from source from the
I was curious what needed to be changed to build the OOPHM plugin for
Firefox 3.5b4. The header files from the 1.9.1 gecko-sdk are
necessary, and the OOPHM library has to be linked against the Firefox
3.5b4 libs, but no changes to the OOPHM source code were required.
The makefile in
Comment by andres.a.testi:
Why not @switch/@case instead of @if/@elif?
For more information:
http://code.google.com/p/google-web-toolkit/wiki/CssResourceCookbook
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
12 matches
Mail list logo
