Lots of good things to discuss in that post.

In particular I am curious about polling because I am using that approach on
www.ChattyGabby.com for the chat interface (only works in HTML5 browsers
like Chrome and Safari).

Right now I think I have it setup to poll every 2 or 3 seconds and the
bandwidth used is very minimal. I don't have a lot of traffic on the site
right now so it definitely works. But I would guess that if a couple
thousand people started using it, that I would run into performance issues.

Would there be a significance difference between waiting on a queue that had
a timeout (say 30 seconds) vs. letting the program iterate and go to sleep,
wake up to check for messages, and then go to sleep for another millisecond
if it didn't find any?

I use *DTAQ's a fair amount to have RPG talk to Java and what I don't like
about them is that the OS doesn't have an easy way/utility to peek at the
entries.

Aaron Bartell
www.MowYourLawn.com/blog
www.OpenRPGUI.com
www.SoftwareSavesLives.com



On Tue, Nov 30, 2010 at 6:43 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

That is a question that came up recently in a PHP group on Linkedin. I
thought
it might also be worth discussing here, too.

Some years ago I became acquainted with a rather robust system for managing
credit unions where the entire UI was implemented through a single command
line
prompt, like a Unix or DOS shell. Quite literally, the only two events that
the
server would respond to were the Enter and Escape keys. Interaction with
the
server would begin by entering a short action code, which would generally
trigger a dialog to enter data into a database, perform transactions, and
so
forth, one input line at a time.

Perhaps surprisingly, users liked it, and became productive with it, but
contrast that type of UI with an HTML page that may be filled with any
number of
visual and input capable elements simultaneously, and using
element.addEventListener() or element.attachEvent() to register a
potentially
broad range of keyboard and mouse event handlers for any number UI element
displayed.

I suppose you could carry the comparison (contrast) even further by using
AJAX
to subscribe to a network service which may be "listening" for events on a
network, and notify each client of it. A good use case might be a moderated
chat
service. It might be helpful to update each user's screen whenever a
participant
on the network enters or leaves the chat service. Maybe you want their name
begin flashing when they begin typing. Every client should be notified the
moment any one of them enters a new message.

I'm not sure how to implement something that in PHP. I assume it can be
done
because Facebook chat works something like that. Using a tool like Fiddler,
you
can see the browser performing an asynchronous request that waits for up to
something like 2 minutes, for the server respond. I assume the server in
turn is
waiting on a queue of sorts. But I'm not aware of the implementation
details on
the server, beyond configuring the HTTP server to allow persistent
connections.


Contrast network listening, vs network polling. Polling from the client at
regular intervals consumes more bandwidth and other resources, and yet is
not
quite as responsive as listening on a queue.

-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.