Ah yes, not enough animal sacrifice in my deployment procedures. That must be a significant part of my problems.
I have dealt with this issue before in standard Java RMI based client/ server applications. However, in those situations, we had a more capable communication pipe between the client and server. There it was possible for the server to initiate communications, and slap around the client if it the users got all uppity and refused to close it. This made deployments rather easy, and stroked our god-complex- driven egos to boot. In GWT (or just the web in general, really), we don't quite have this. At least not without some hacky client polling, which I find just slightly less than elegant. I do agree with the point about not really being able to provide a common solution to the issue. It would be a bit odd if GWT locked us into a more rigid communication structure in order to auto-magically handle version differences. Additionally, having the framework force a browser refresh seems a bit evil, and I don't like evil, as a general rule. Now I just need to find a cow to murder for the next release ... GWT: Its delicious beef-flavored development. -Ben On Dec 13, 10:38 am, Jeff Chimene <[email protected]> wrote: > On 12/13/2010 08:52 AM, Ben Imp wrote: > > > > > Excellent - I am not alone in my troubles. On second thought, perhaps > > rejoicing in the sharing of pain is not the most healthy viewpoint to > > take ... > > > The post to the older discussion was quite useful. The blog linked > > there has some pretty good information on how this same issue has been > > dealt with in the past, and some other issues that I haven't yet had > > to deal with. In the end, it seems that it all comes down to crafting > > your application in such a way that it is able to perceive its out-of- > > dated-ness (English is awesome) and inform the user of the potential > > errors, or just force them to do the Right Thing and reload the > > application. The latter seems like a more sane thing to do, given the > > similarity of instructing users to herding cats. I suppose false > > positives are something that might be in issue in that case, and an > > epileptic application may result, but that should be easy enough to > > discover in testing. > > > I agree that this should be mentioned in the documentation as well. > > It seems like something that is much easier to deal with if you > > consider it from the beginnings of your application, as opposed to > > running into it (or, perhaps, more appropriately, stumbling into it) > > somewhere down the line. One would assume the Google guys (aka Sir > > Developer Not Appearing In This Thread) have dealt with this, since > > their AdWords UI is (if I recall correctly) based on GWT. I would > > likewise assume that product has a fair number of active users at all > > times of day, and they are probably as hesitant to drive around the > > world as I am. > > > I would be most intrigued to see what they have done internally. I > > imagine it involves pixie dust and invisible pink unicorns. > > And slaughtering a goat on the keyboard. > > ISTR that this issue is similar to the authentication/authorization > issue in that there exist many implementation-specific constraints. GWT > gives you enough information to make a run-time decision about > out-of-dated-ness. > > To be fair, this issue surfaces in any long-running client-server > application suite (e.g. COBOL/IMS) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
