News for hackers. Stuff that matters.
Re:Asynchronous UIs - the future of web user interfaces by stingraycharles on Wednesday November 16, 2011 @03:00PM (#3244806)
But at that point, you still have a blocking call to put it on the queue at Google's servers. Which can just as well be, well, a mail server (which maintains a queue of itself). So adding another layer of abstraction on top of it kind of defeats the purpose.
Re:Asynchronous UIs - the future of web user interfaces by iradik on Wednesday November 16, 2011 @04:39PM (#3245199)
Interesting point, but what happens if you click "send!" and then close your laptop. Is your message sent or not?

While your point about the server-end being a queue is true, there's an expectation once your message is offloaded onto Google's queue, they will reliably process the message in a reasonable amount of time.

Re:Asynchronous UIs - the future of web user interfaces by brown9-2 on Wednesday November 16, 2011 @09:10PM (#3246105)
How is that call to put it on the queue "blocking"? "Blocking" is being used here to describe the UI preventing the user from further interaction (such as reading a different email) until the server acknowledges receipt. You can still wait for queue acknowledgement without preventing the users from browsing to other parts of the app.
Re:Asynchronous UIs - the future of web user interfaces by noahl on Wednesday November 16, 2011 @06:20PM (#3245635)
Ah, but the queue doesn't exist on Google's servers. It's purely on your computer.

So the idea is that instead of time-consuming, blocking operations, you have fast blocking operations that put things in queues, and the queues then handle the slow operations.

Re:Asynchronous UIs - the future of web user interfaces by movingahead on Thursday November 17, 2011 @01:54AM (#3246719)
GMail Labs has a "send in background" feature which does exactly this.