Well, it seems like we have a pretty strong sense that long
polling/Comet might be overkill for what I have described. What I glean
from this all is:
a. Simple is better unless you REALLY need fancy.
b. Normal polling with appropriate intervals should suit most
applications, or at least mine.
c. No need to hit the DB every time. Render a static file periodically
and use that.
d. Wait for Websockets. Maybe. If you really need it.
Meantime, I've been using the static data file deal for a while.
Hmm. Maybe a neat trick would be to pass a value in the data for
"refresh = n" where n = the suggested refresh rate, including 0 for "do
not refresh"
That way I can scale the traffic when I have to, and can turn off
updating when the event is over.
Michael
On 5/23/2011 7:32 AM, Arnie Shore wrote:
I have to agree with Sanjay on this.
I use conventional polling based on a client-side timer of 15 seconds
in my CAD/Situation-Awareness application, with the server responding
immediately. (This is after a long and hard look at alternatives.)
Simplicity itself, and readily tested and tweaked as necessary.
My concern with Comet/BOSH/etc. was re testing; I'm not alone among
developers in not having a realistic operational environment as a test
bed, so simplicity and ready visibility into the app's operation is
key, IMO. Those packages, despite their merits, represent another
black box that might defy comprehension.
Websockets has the potential to change my thinking, however, once it
reaches some level of maturity. It seems to represent a clean
approach to the problem, with apparently direct visibility into its
operation.
AS
On 5/23/2011 2:55 AM, Sanjay Bhangar wrote:
hey,
I have some experience building a "real-time collaborative" app -<big
snip>
_______________________________________________
Users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/openlayers-users
_______________________________________________
Users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/openlayers-users
