Thanks for the review. Are there instructions somewhere for building the IE and WebKit plugins? I have MSVC setup in VMWare, but I don't have Xcode setup on my MBP.
http://gwt-code-reviews.appspot.com/51834/diff/1/11 File plugins/common/ChooseTransportMessage.cpp (right): http://gwt-code-reviews.appspot.com/51834/diff/1/11#newcode31 Line 31: * Receive an FatalError message from the channel (note that the message On 2009/08/07 19:46:49, bobv wrote: > Copy-and-paste? Will fix. http://gwt-code-reviews.appspot.com/51834/diff/1/13 File plugins/common/FatalErrorMessage.h (right): http://gwt-code-reviews.appspot.com/51834/diff/1/13#newcode27 Line 27: * Class representing an InvokeMessage received from the server, and a way On 2009/08/07 19:46:49, bobv wrote: > Copy-and-paste? Will Fix. http://gwt-code-reviews.appspot.com/51834/diff/1/26 File plugins/common/ProtocolVersionMessage.h (right): http://gwt-code-reviews.appspot.com/51834/diff/1/26#newcode27 Line 27: * Class representing an InvokeMessage received from the server, and a way On 2009/08/07 19:46:49, bobv wrote: > Copy-and-paste Will fix. http://gwt-code-reviews.appspot.com/51834/diff/1/17 File plugins/common/SwitchTransportMessage.cpp (right): http://gwt-code-reviews.appspot.com/51834/diff/1/17#newcode29 Line 29: * Receive a SwitchTransport message from the server. On 2009/08/07 19:46:49, bobv wrote: > What is this message type used for? The intent is to allow a plugin to advertise a list of alternate transports it supports, and allow the server to choose an acceptable one considering what it supports and the address of the connection. An obvious example would be shared memory, using the work that Sam did last year. http://gwt-code-reviews.appspot.com/51834/diff/1/27 File plugins/common/SwitchTransportMessage.h (right): http://gwt-code-reviews.appspot.com/51834/diff/1/27#newcode27 Line 27: * Class representing an InvokeMessage received from the server, and a way On 2009/08/07 19:46:49, bobv wrote: > Copy-and-paste. Will fix. http://gwt-code-reviews.appspot.com/51834/diff/1/2 File plugins/webkit/Core/WebScriptSessionHandler.cpp (right): http://gwt-code-reviews.appspot.com/51834/diff/1/2#newcode97 Line 97: Debug::log(Debug::Error) << "Fatal error: " << message << Debug::flush; On 2009/08/07 19:46:49, bobv wrote: > There's a CrashHandler mechanism already built into the plugin, you can call > that to initiate an orderly shutdown. Ok thanks, I will use that. http://gwt-code-reviews.appspot.com/51834/diff/1/5 File plugins/webkit/Plugin/OophmWebScriptObject.mm (right): http://gwt-code-reviews.appspot.com/51834/diff/1/5#newcode98 Line 98: - (BOOL)initForWebScriptWithJsniContext: (WebScriptObject*) jsniContext { On 2009/08/07 19:46:49, bobv wrote: > Just to confirm that this is intended to be a no-op? Well, it should return true if the plugin is properly initialized and reachable from the hot page. A plugin that needed the hosted.html window object would stash or use it, and if there were any other "i'm ok" checks they would be performed here. Mostly, this is so that a failure to call plugin.init can be detected as an error getting the plugin running, separate from plugin.connect failing meaning it couldn't get the connection to the server running. http://gwt-code-reviews.appspot.com/51834 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
