[Dojo-interest] Marshalling support

[Jason Carreira]

On 5/19/05, Alex Russell <alex at dojotoolkit.org> wrote:
> 
> 
> > For example bad network latency can leave users thinking their
> > request failed then 5 seconds later it completes (after they clicked
> > a few more times for luck).
> 
> Well, more likley, the user might be left to think that their action
> hasn't complted. Good apps work around this by giving instant feedback
> (where possible) and some measure of progress. 5 second is actually a
> surmountable amount of delay so long as you're not blocking a user's
> "flow". Remember, user's don't make requests...they try to get things
> done. WE make requests.
> 
> > At a first level, async requests really
> > need their status communicated to the user interface.
> 
> Beyond "thinking..." and getting out of the way of the user? I think the
> real question here is what level of tying to server-side capability
> we're talking about. Telling the user that you're doing work on their
> behalf and that it's going to take some time is usually enough to set
> expectations so long as you're not doing it very frequently.


What's the status of synchronizing XHR requests? Could we queue them up to 
be sent over the pipe? This whole discussion had me thinking of button 
clicks leading to a little icon flying over to an outbox with a counter 
showing the number of queued messages to be sent to the server...

> My approach, as
> > a first attempt, was making sure async requests "time out" after a
> > given number of seconds (using setInterval to call the XMLHTTP abort
> > method) - this at least gives a chance to handle this. That even lead
> > me to thinking it would be useful to have some kind of Javascript
> > latency "poller" which adjusts the timeout value by testing the
> > network - in practice probably bad news.
> 
> Paul Sowden has already mentioned to me the need to allow canceling of
> requests. I think he's right. A timeout is also an intersting idea.
> Would you want to have a "failed" event thrown as a result?


Absolutely!!! This is absolutely necessary in an async world. You need to be 
able to have compensating transactions or at least let the user know that 
something they were trying to do failed... In really complex cases it might 
not be so simple to get the page to a consistent state in that case, and you 
might want to warn the user that you're going to refresh the whole thing 
from the server. 

> You can have other strange things happen though where a first async
> > request completes after a second. For io.bind, that might mean a user
> > clicks back twice and ends up on the "url" from first click, not the
> > second. That probably means the client needs to take care making sure
> > the responses from multiple requests are handled in the right order.
> 
> Well, the back button handlers are synchronous. Given that a stack is
> used to keep track of "where" we are in the forward/back stream, it
> shouldn't be possible to get out of order easily. What might not be
> sychronous are bind() requests kicked off by those handlers, but to
> some extent, that's the programmer's problem.


I haven't looked that much at the back button stuff, but here's a scenario 
that I just thought of...

Let's say I'm showing a catalog that someone is shopping in, and 
asynchronously updating their shopping cart when they add items, sending an 
XHR message to the server and having it update the shopping cart display. 
Now let's say the user wants one more item, adds it to the cart, and quickly 
clicks the checkout button... which one gets through first, the shopping 
cart add or the checkout? What if my policy is that things like checkout are 
synchronous full-page requests to the server?

These edge cases are the kinds of issues that are going to bite people, and 
Dojo should have good answers out of the box.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dojotoolkit.org/pipermail/dojo-interest/attachments/20050520/47d7ce05/attachment-0001.html