Notification support in browsers.

a reply to: ArMaP

Mostly at any time, about 200-300 users are on-line, and even if they all queried simultaneously, that should not be any problem.

Of course, if one would build such a system, a lot more members would stay on-line, just to get the notifications...

A lot depends on how you design this. My crude examplecode requires a PHP program to be loaded in memory and executed, which takes time. If it also needs to set up a database connection, create and issue a query - it takes more time. On the other hand, the entire ATS site consists of such PHP programs, which are constantly loaded in memory - and if used sufficiently, will remain in memory, which makes them much faster.

Modern databases can literally handle tens of thousands of queries per second (of course depending on how well the db design and tuning was done ("use the Index, Luke!"), and it are very small queries (just passing an authentication string and getting a short string in return). Also, given that ATS would be in control over the clients, an algorithm can be created to spread the queries equally in time, e.g. by providing a field that tells the client how long to wait before polling again. This, and disallowing more than one query per session / member / time, should result in barely noticable performance losses.

The better question for ATS owners, of course, is: does this create more profit? Well, members stay on-line longer and visit the site more frequently - and hence more ads would be shown. Not sure about the deal ATS made with the ad networks, but if merely having ads show up on the end users site makes them money, they would probably make more money. But OTOH, writing and debugging software can be a costly business.

It's entirely up to SO, of course.