On 12/13/2010 10:55 AM, Ben Imp wrote: > 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.
GWT's reliance on browser refresh has to satisfy two competing objectives: caching and on-line updates. It's also the case that nebulous documentation exacerbates the tension between those objectives. The informal nature of much on-line documentation encourages the failure mode that is this thread's subject. Is the expectation that we now mashup N blogs, wikis, javadoc et. al. just to achieve parity with professionally created documentation? Software's rapid development pace makes a farce of documentation's craft, yet it's that parody upon which we now rely. > > 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.
