[Sorry if this gets duped; got 502 error from Groups posting UI....]
>From the Gears/GWT thread, Scott said:
"BTW: The reason the server couldn't simply send the client a directly-evalable string is that the server doesn't know the obfuscated symbol names of the various fields and constructors. If the server DID know those symbols, we could probably make deserialization an order of magnitude faster. But that's a separate discussion. :)"
This thread is that separate discussion!
Why can't the server know the obfuscated symbols on the client? Is it to prevent the server from having to be aware of what client-side compilation mode was used? Could there be some kind of dictionary that the GWT generator builds, that could be put on the server's classpath as a resource, and loaded (if present) to enable server-side direct-eval response construction?
The key questions are: 1) is this breaking some important information hiding that you want to maintain over the wire? 2) how large would the performance increase actually be? 3) is this moving in the direction of something like a generic JSON- ish wire format that would let the server part of GWT RPC be used by NON-GWT clients?????????
4) What's more important, server-side performance (of RPC response construction), or client-side performance (of RPC response deserialization)?
If you care more about user experience (e.g. not blocking the UI thread), you probably care more about client-side performance. If you care more about server scalability, you probably care more about server-side performance....
On 6/6/07, Rob Jellinghaus <rjellingh...@gmail.com> wrote:
> 1) is this breaking some important information hiding that you want to > maintain over the wire?
I'm not sure what you're hinting at here, but I'd like to get in early with "security by obscurity is not secure". If anyone is relying on GWT's wire format being obfuscated for security reasons, they're already hosed.
> 4) What's more important, server-side performance (of RPC response > construction), or client-side performance (of RPC response > deserialization)?
I have to vote for client-side performance being more important. If my server is too slow I can buy a bigger one or another one. If my client is too slow, I can do nothing more than beg my customer to buy a newer machine.
On 6/6/07, Rob Jellinghaus <rjellingh...@gmail.com> wrote:
> Why can't the server know the obfuscated symbols on the client? Is it > to prevent the server from having to be aware of what client-side > compilation mode was used?
Compile -style mode, source/class versions, deferred bindings, possibly the order of the parts of GWTCompiler's classpath/sourcepath could all affect that naming of obfuscated methods.
To do this you would need to tie the server classes to the generated JavaScript. One change in one would necessitate the recompile/deploy of the other. This would seriously negatively affect refresh cycle of people who use the no server mode.
-- Sandy McArthur
"He who dares not offend cannot be honest." - Thomas Paine
On Jun 6, 11:30 am, "Sandy McArthur" <sandy...@gmail.com> wrote:
> Compile -style mode, source/class versions, deferred bindings, > possibly the order of the parts of GWTCompiler's classpath/sourcepath > could all affect that naming of obfuscated methods.
> To do this you would need to tie the server classes to the generated > JavaScript. One change in one would necessitate the recompile/deploy > of the other. This would seriously negatively affect refresh cycle of > people who use the no server mode.
This is exactly what I was alluding to when I mentioned "information hiding" between server and client.
Given that doing this does require a full server/client deploy cycle (since the server needs state generated from the full client build), and given that there are tradeoffs about whether you want to optimize the client deserialization at the expense of the server's performance (and at the expense of your build cycle), it feels like this would definitely have to be an optional optimization. Basically it'd need to be a final-deployment step once your main development is nearly complete and build turnaround is less critical. Those who want the server serialization to be fast could do without it altogether.
And again, exactly how much of a win it is (given the considerable effort required!) is completely subject to discussion.
> I have to vote for client-side performance being more important. If > my server is too slow I can buy a bigger one or another one. If my > client is too slow, I can do nothing more than beg my customer to buy > a newer machine.
I vote server-side performance being more important. I am less than happy with my explanation, but I have yet to think of a better way to say the following: As server-side work scales with the number of users, so does the savings given by any server-side optimization. The client side's optimization has a much smaller visible impact as each user sees a constant improvement, not a scaling improvement...
Also, my server is going to get run to its limits. My site is going to have more than a mebibyte of downloaded code before a user can use the interface. I expect my audiance to be primarily broadband users, people who, I expect, will have more than enough headroom to deal with the lack of client-side optimization...
with the server returning an eval()-uable string, we could also move in the direction of allowing cross site (JSON style <script> injected) RPC for GWT mashups. There's still an issue with the amount of info that can be sent via the <script>'s get, but I still think it is a compelling idea.
-jason
On Jun 6, 2007, at 12:41 PM, Rob Jellinghaus wrote:
> On Jun 6, 11:30 am, "Sandy McArthur" <sandy...@gmail.com> wrote: >> Compile -style mode, source/class versions, deferred bindings, >> possibly the order of the parts of GWTCompiler's classpath/sourcepath >> could all affect that naming of obfuscated methods.
>> To do this you would need to tie the server classes to the generated >> JavaScript. One change in one would necessitate the recompile/deploy >> of the other. This would seriously negatively affect refresh cycle of >> people who use the no server mode.
> This is exactly what I was alluding to when I mentioned "information > hiding" between server and client.
> Given that doing this does require a full server/client deploy cycle > (since the server needs state generated from the full client build), > and given that there are tradeoffs about whether you want to optimize > the client deserialization at the expense of the server's performance > (and at the expense of your build cycle), it feels like this would > definitely have to be an optional optimization. Basically it'd need > to be a final-deployment step once your main development is nearly > complete and build turnaround is less critical. Those who want the > server serialization to be fast could do without it altogether.
> And again, exactly how much of a win it is (given the considerable > effort required!) is completely subject to discussion.
It doesn't seem to me that the optimization under discussion would make a lot of difference either way on the server. In fact, if the server-side serialization code is generated, there's no reason it couldn't be pretty much optimal.
As Sandy points out, though, generating code on the server is a bit of an issue if you don't want to recompile your server all the time. Maybe there's a way to make this optional, but it is certainly a consideration.
One benefit to the client I want to mention is that, in addition to making the code much *faster*, it will also make it much *smaller*. The deserialization code can be quite significant, and I'm all for doing anything that eliminates client code.
joel.
On 6/6/07, The Class Connection <theclassconnect...@gmail.com> wrote:
> > I have to vote for client-side performance being more important. If > > my server is too slow I can buy a bigger one or another one. If my > > client is too slow, I can do nothing more than beg my customer to buy > > a newer machine.
> I vote server-side performance being more important. I am less than happy > with my explanation, but I have yet to think of a better way to say the > following: As server-side work scales with the number of users, so does the > savings given by any server-side optimization. The client side's > optimization has a much smaller visible impact as each user sees a constant > improvement, not a scaling improvement...
> Also, my server is going to get run to its limits. My site is going to > have more than a mebibyte of downloaded code before a user can use the > interface. I expect my audiance to be primarily broadband users, people > who, I expect, will have more than enough headroom to deal with the lack of > client-side optimization...
On 6/6/07, Jason Essington <jason.essing...@gmail.com> wrote:
> with the server returning an eval()-uable string, we could also move > in the direction of allowing cross site (JSON style <script> > injected) RPC for GWT mashups. There's still an issue with the amount > of info that can be sent via the <script>'s get, but I still think it > is a compelling idea.
Note that there are security considerations involved here -- if you make the return directly evalable (without stripping off // or something similar), you not only allow cross-site RPC but CSRF as well. To prevent that, you need to add some authentication token in the GET request and have the server not send sensitive data if it isn't present.
Not saying there isn't value in cross-site RPC, but that doing it opens a lot of security issues.
> It doesn't seem to me that the optimization under discussion would make a > lot of difference either way on the server. In fact, if the server-side > serialization code is generated, there's no reason it couldn't be pretty > much optimal.
> As Sandy points out, though, generating code on the server is a bit of an > issue if you don't want to recompile your server all the time. Maybe there's > a way to make this optional, but it is certainly a consideration.
> One benefit to the client I want to mention is that, in addition to making > the code much *faster*, it will also make it much *smaller*. The > deserialization code can be quite significant, and I'm all for doing > anything that eliminates client code.
Ooooh. That's a nice point. Ripping deserialization code out of the client would be great.
> > > I have to vote for client-side performance being more important. If > > > my server is too slow I can buy a bigger one or another one. If my > > > client is too slow, I can do nothing more than beg my customer to buy > > > a newer machine.
> > I vote server-side performance being more important. I am less than > > happy with my explanation, but I have yet to think of a better way to say > > the following: As server-side work scales with the number of users, so does > > the savings given by any server-side optimization. The client side's > > optimization has a much smaller visible impact as each user sees a constant > > improvement, not a scaling improvement...
> > Also, my server is going to get run to its limits. My site is going to > > have more than a mebibyte of downloaded code before a user can use the > > interface. I expect my audiance to be primarily broadband users, people > > who, I expect, will have more than enough headroom to deal with the lack of > > client-side optimization...
The more I think about relying on knowing the compiler's generated symbols, the more it seems like a fool's game to me; they would be different on every permutation (so you'd have to know which perm the client was running), and it seems like it RPC and the compiler would have to be way too closely tied.
Maybe a more promising approach would be that the client could somehow produce an eval enviroment? IE: expose well-known symbols into this environment that could be statically infered. It'd make the client-side code a little bigger, but might be speedier. We should perhaps mock something up and analyze what the potential performance boost would be.
