RIAs and VOs and server data...oh my!

[CDHBookingEdge]

This is another one of those "Am I totally missing the concept here?" type questions.

Now RIAs are/”can be” defined as online applications that provide a look and feel that users are used to seeing in their desktop applications. Thereby bringing about a certain familiarity and easing the use.

Another part of the definition as far as RIAs that I've noticed thru my (possibly sporadic and non-structured) reading is attempts to get rid of the "call to server then wait for response" type format. Thereby speeding up reaction/performance of the program and theoretically, the effectiveness (and happiness) of the user in getting completed their tasks.

Also I've been reading about the use of VOs, value objects, essentially data classes. (I'm assuming that you guys have much more familiarity with them than I do, if not then, well that is for another discussion I suppose, LOL.)

So, based on those premises (which anyone who wants to can take shots at, and in a way please do.), here's the way my mindset is working. I'll use a specific example or two as a basis to give us something to wrap our heads around.

Let's take an online store as an example. In the flexstore example they use an XML file to store the data (catalog.xml) They have not implemented the search feature. (I know I used the word flex here but really it's only a tool or a venue, still the concept is towards program structuring and organization.) Now in a typical "old style web program" a query would be posted to the server, this query would be then passed to the database residing on the server. And then the user would wait while an attempt was made to contact the server and search thru the dataset... you get the picture. Now isn’t that something we’re supposedly trying to warrant against? I mean the user wants to have a feeling of, “Bing! Bang! Boom! Yes! I am a god!” right? I mean all the pretty flashing around doesn’t give a user the feeling that the program is reponsive and functional right? Flash gives us (admittedly a gross understatement) the pretty pictures, but along with that is also a need for familiar interactions, and also reasonably quick response, isn’t that right?

So isn’t this in a way the perfect place for VO’s, for client existing data classes? Or is this the place for the usual “call to server, wait, server sends you data” kind of perspective that we’ve almost become too used to?

To an extent the real question (at least in my mind, boils down to this): How much of the data should be passed to the client so that it is quickly accessible, and what are the best practices that can be used to effectively manage this?

Anyway I just thought I would throw this out there for discussion and see what possible ideas might come about

[jsebrech]

To begin with, in a multi-user system client-side data should rarely be more than a temporary edit buffer or a local data cache, so if you're reading data that can't or shouldn't be cached, you're forced into server roundtrips anyway.

In most cases though, data is cacheable, and in that case it only makes sense to cache the data that will actually improve average-case usability. Preload too little, and the user is waiting too long for the server roundtrips, preload too much, and the user is waiting too long for the application to load initially. This is very project-specific. And that is why there's no generic answer to your question.

But, to put it simple: know your average case, and know your worst case. By that I mean that you should design your application so the average user has the optimal experience, but the slowest user has a usable experience. Taking into account that almost all web applications have analog modem users, the worst case is quite likely to be 5 KB per second, which means you should be careful about preloading too much data.

[CDHBookingEdge]

You say And that is why there's no generic answer to your question.
But there are heuristics right? So you're saying that, if it's getting thru my thick head :) :
A) A knowledge of the data and it's source and the amount of it's possible content is imperative to proper implementation of the system to warrant against the "too little" or "too much" problems.
B) VOs are a possible and probably good choice for RIAs but the precepts of (A) must be kept in mind.

Is that right? Did I interpret it correctly? And if so then would a data structure be able to be devised that had flags and info in it to know these heuristics? By that I mean a "somewhat generic" data class that has for example (this is just off the top of my head) a bool denoting if it's a chunk or the full content. Some numeric variables that provide info as to how much of a chunk it is. Then the specific data class could be developed as a subclass of this somewhat generic class.

For example something like this:

package myStuff
{

class kindagenericdataclass
{
public var isChunk:Boolean;
public var notsurewhatotherdataisneededrightnow:int;
(other support stuff)

}

}


and then the VO code could be written something like this:

package program.VO
{
class users extends myStuff.kindagenericdataclass
{
var name:String; // username
var password:String; // user password

}
}


Does that seem feasible or totally off base to you? If I'm not totally off my rocker here (which may be the case) then do you have any ideas on some of the heuristics that might be used? Or places to look as far as discovering those?

Christopher

[jsebrech]

There are too many factors you have to take into account. You can definitely build a set of disparate tools though. For example, I have built a XML loader class that serializes load requests so that at most one request is running at any one time. I did this because the requests in my case went to PHP, inside a PHP session, and PHP can only handle one of these requests at a time, so I was opening up a lot of requests to the server that it couldn't handle (and that started timing out after a while).