× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



That's why I really think something like Atmosphere is a better solution: it abstracts the transport layer. As a result, you don't have to care (very much) whether the client or server is capable of websockets, comet (long-polling), or regular polling. The framework will negotiate that based on the capabilities of both ends.

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Thursday, July 12, 2012 6:01 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Websockets on the IBMi

From: Maurice O'Prey
Nathan, I know what web sockets are ...


Did I say something that was already exceedingly obvious? I'm still feeling remorse for asserting at the beginning of this thread that Web Sockets implemented a request-response cycle just like XHR. I should formally apologize to Kevin Turner and Kevin Schroeder. They tried to correct me, but I held my ground. Now I'm embarrassed. How tedious my ignorant assertions must have been!

Now I understand that once a Web Socket connection is opened, it goes in to "listen" mode. When messages are received, the "onMessage" event is triggered, and its event handler is called. The server can push data to the browser at any time while the connection remains open.

That's not the traditional HTTP request-response cycle. So I apologize to Kevin and Kevin, and any others who knew better. I apologize for any confusion I may have caused.

Nevertheless, I'm still struggling between the choices of using Web Sockets vs. XHR for streaming messages to one or many browsers the moment an event occurs on the network. I can set up the HTTP server to use persistent connections. I can use XHR to wait for broadcast messages. I don't mind connecting to an HTTP process that might spend most of it's life in a *zero CPU state, waiting for event notifications from wherever. It may not be worth the effort to develop or deploy a separate Web Socket server.

Whatever the underlying protocol, I still like the "meeting" metaphor. Maybe the only participants in the meeting are one browser and one server that forwards phone call messages, or whatever to it. I like the idea of one participant "opening" and "closing" a meeting, all participants "joining" a meeting, and all participants sending and receiving messages within that context, without every worrying about how messages are routed; they only need to know a meeting ID.

-Nathan.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.