Hi Jorge,
But, ISTM, in the end it's ~ === a [non-persistent :-( ] socket... and
each and every socket is tied to a thread too... per user (unless
you've got some sort of multicasting). Isn't it so ?
My issue is with the persistence of server-affinity. At least when genuine
polling isn't masquerading as something else, the affinity is transitory and
a limited number of processes/threads are able to service the requests of
many thousands of Ajax clients. With your "German beach-towel on the
deck-chair" paradigm, we all end up sitting on the concrete while so many of
those servers/threads/sun-loungers go begging :-(
Yes, "multicasting" would be ideal and doable (athough why Applets from the
codebase still have to be signed to receive a multicast is beyond me :-( )
but please do not dismiss simple UDP datagrams so lightly! Where 'n' number
of clients subscribe to a service (stock-ticker?) and when something
"interesting" happens a single thread/process updates/broadcasts the
interested parties. (Happy to discuss the addition requirements of this
strategy if anybody's interested.)
IMO whoever calls that whatever-*polling* is plainly wrong: event-
driven === the exact opposite of polling.
Maybe? I'm happy to concede the point. It's certainly asynchronous and an
event does occur in the client. But hopefully you can also be as open-minded
when it comes to dismissing the bogus "server-push" nomenclature? You've
asked for a Big Mac and fries and are sitting in the drive-thru lane; don't
ask everyone else to share your surprise when someone hands you a burger and
fries! *What'smore* don't ask anyone to get all excited about the fact that
for *every* additional concurrent request yet another car is added to the
queue for your apple-pie and happy meal :-(
This is yesterday's technology (snake-oil and mirrors) for people who are
still impressed with anything above static pages. Flex has had TCP/IP
Sockets for years! Silverlight has jumped in boots 'n' all! HTML5 WebSockets
are a joke :-( But Java is still the only full blown Socket infrastructure
available to your (+/- web) clients.
Embrace it!
Cheers Richard Maher
(...)
PS. Not wanting to get involved but my 2 cents say it's clearly long-polling
regardless of whatever else you may call it. (Or how much lipstick you put
on it
And with one server process/thread instantiated and/or tied up for
per user, it's not a very pretty pig either!
But, ISTM, in the end it's ~ === a [non-persistent :-( ] socket... and
each and every socket is tied to a thread too... per user (unless
you've got some sort of multicasting). Isn't it so ?
IMO whoever calls that whatever-*polling* is plainly wrong: event-
driven === the exact opposite of polling.
My $0.02
