On Sep 18, 8:45 am, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> 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 ;-) )
You take it somewhere that sounds ridiculous, while all I was getting
at was that GWT RPC might be modified slightly in order to use plain
old HTTP GET where it fits. I.e., simply specified queries where
cacheing and safety matter.
>
> > 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).
If there was a way to configure RPC so that the method name mapped to
a URL path and the arguments mapped to query parameters and the method
was annotated as @UseGET, and maybe some other stuff, then couldn't
this make rather good use of HTTP and reap the benefits of that?
>
> > 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...
Sure. Maybe I wasn't clear before that I'm thinking in terms of minor
enhancements to GWT RPC for these features.
>
> > 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?
To be honest, I've forgotten the exact reason. I think it has to do
with the fact that browsers get images using GET, and there are XSS
attacks that exploit that so that using POST for everything is safer.
>
> > 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.
All well and good, Thomas. Wouldn't it be nice to be able to do that
stuff via GWT RPC, and how infeasible is that?
I think overall it would have been better to say "GWT RPC may not
scale as well as it could if it used HTTP cacheing protocol more
extensively" than to say "GWT RPC is not RESTful". That way I get a
better idea of what my choices are.
By the way, a technicality: REST does not require cacheability of
resources. It only requires that agents convey whether or not
resources may be cached. So cacheability is not a direct benefit of
REST. Knowing what resources may be cached is.
Thanks,
Walden
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
