On 18 sep, 14:06, walden <[EMAIL PROTECTED]> wrote: > Hi Thomas, > > Thanks for spelling that out. > > I do agree that GWT RPC might be less cache-friendly out of the box.
And that was my main point (if you're a "pragmatic developer" ;-) ) (along with conditional GETs which you'd have to "emulate" with GWT- RPC: add an ifModifiedSince parameter to all your methods and a lastModified timestamp to your returned objects; ...and now you're effectively tunneling HTTP within HTTP ;-) ) > As far as the folder templates story, while I understand that the ACL > list is cacheable for hours at a time, it seems to me that if folder > content is allowed to change in realtime, or if user roles are updated > in realtime, then the interactions for content are going to be mostly > un-cacheaable, and being able to cache ACLs doesn't seem to buy all > that much. Yes, of course, it was an example (derived from our app). As you point out, we do have realtime-changing "roles" which make our resources uncacheable (or at least not as cacheable as in my example). As for the realtime-changing folder content, that's not really a problem if you design your resources carefully (if the subfolders are cacheable for hours but not their contents, then just make them distinct resources); but conditional GETs –which you don't have with GWT-RPC– could still save bandwidth (for sure) and processing time (if you've carefully designed your server, i.e. first check If-Modified-Since and the like then, only if you need to send fresh data, do the computing and processing and serialization/formatting). > I think making "safe" RPC requests via GET should be an option in > GWT. I'm not sure how to do that, Without a server-side API to communicate the Last-Modified/ETag and check them against If-Modified-Since/If-None-Match/etc. request headers *before* actually requesting data and process and serialize/ format it, it wouldn't be of much help... > and I'm also aware that there are > XSS concerns around doing that. really? Related to "authentication through a method argument" rather than HTTP-level (RFC2616 / RFC2617) authentication? > If I were in your shoes, I would probably build a special intermediary > for serving GWT facing content and let that have a pure REST > relationship with the independently evolving head end. Just a > thought... We're not yet scaling that big yet actually ;-) so non-cached resources will work for now (and our server-side framework only allows us to save bandwidth with conditional GETs, not save server-side processing :-( ), but using ROA rather than SOA will ease scaling in the (not that far) future. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
