Hi Loic, The Long polling transport method is the most "cross-browser" way to do realtime request (unlike forever iframe, xhrstreaming, websocket, and so forth). This is what our framework do : http://www.ape-project.org/
APE is a client-side and server-side application. It can be easy implemented to jpoker or another existing app. Sadly I didn't find the time to work on a port of jpoker/APE, but I'm sure that someone can be interested :-) Anthony Loic Dachary a écrit : > Hi, > > I gave some thoughts to the implementation of long polling ( > http://en.wikipedia.org/wiki/Push_technology#Long_polling ) client > side (jpoker & pok.me). At the moment, all XHR calls are queued in > such a way that request sent at T+1 won't be sent until the request > sent at T was acknowledged. If implementing long polling, the > PacketPoll packet must be an exception to this rule. If there is a > pending PacketPoll request, any other packet can be sent even if no > answer was received. > > Server side it means that when a packet is received, if there is a > pending PacketPoll it must return immediately, before the new packet > is handled. > > I've not really thought this thru. I think this is all we need to > implement long poll but I may have overlooked an important aspect of > the problem. > > I'd like to hear what you think :-) > _______________________________________________ Pokersource-users mailing list [email protected] https://mail.gna.org/listinfo/pokersource-users -- Anthony Catel - Développeur web & associé Weelya - Improve the web 32 rue du faubourg boutonnet 34090 Montpellier Tel : 04 67 169 778 http://www.weelya.com _______________________________________________ Pokersource-users mailing list [email protected] https://mail.gna.org/listinfo/pokersource-users
