http://25fe8.infofonte.com/codicefiscaleit/ http://262fe.infofonte.com/copioniteatrali/ http://262fe.infofonte.com/truetones/ e72ece221d9974c18e4b752cbaa0a4f4 bab082b56459094297aaec359c3273c9

I did some experimenting with disconnected result sets under ASP.NET, local manipulation of data, then re-uploading the data. That’s part of ASP.NET’s answer to massively scalable web apps. And now that I’ve generalized this Ajax/OpenRico technique, I’m never going back. Whereas millions of records become fast and manageable, dozens of records become blazingly fast. HTTP latency is hardly noticeable. Webserver and database speed is almost a non-issue. Page reloads appear to have been the biggest culprit. Local data manipulation or Ajax can eliminate page reloads. But my plan is to stay consistent with my implementation, whether it’s millions of records or dozens. It’s just that fast.

Thanks for the comments!

This does certainly lead to some very interesting discussions about how much to put on the client vs the server. One has to have a good knowledge of all the issues such as request latency, DHTML latency (particularly innerHTML calls), script size and data pre-loading.

I think that for web application development in particular it is also very important to consider, as I mentioned, the data persistance features of Internet Explorer (which may be on their way to Mozilla). This can make something like Backpack even more responsive. For example, when new tasks etc are added they can be added to the client data store and sent to the server at an appropriate time. The next time the application is accessed the only data to transfer from the server to the client is any updates that may not be in the client data set. Of course this is not something that can be done with all of your Google emails but at least it can store the last X emails you received and just upload the newest ones when you reconnect.

Well I think that I am going astry now but suffice it to say that all these issues need to be considered in the context of ones application and there are certainly no stead-fast rules at this point in time.

It is kind of funny actually, I was just putting together a Yahoo! search example for our Ajax ComboBox and Grid components when you put up your sample!

Anyhow, keep up the great work and I am sure we will be seeing amazing Ajax apps from Yahoo! very soon. Good luck!

Excellent points.

Yes, I am coming from the large data set world.

I have in previous places (nextjet) implemented client sorting for a table and it worked well. Although it added a little more to the client JS (but that was easily encapsulated.)

One of the assumptions we often make in dealing with getting data through ajax is that the latency is low or that the server can fetch data quickly.

When I wrote the original data grid at Sabre, I emulated the Java Swing Table Model, so an initial fetch was made to the real server data and then the 10,000 rows would be cached in the app server containing the table model. Subsequent ajax calls fetch from the memory of the app server. This caching smooths out some of the latency issues.

This is actually leads to some very interesting discussions about how much to put on the client vs. the server. With things like SVG, Flash we started migrating more to the client. With Ajax it seems to lead us to push data back to the server but with rich DHTML it pushes more gui to the client.

Thanks for the excellent feedback.
Bill