SMF Development > Next SMF Discussion

More flow to SMF.

(1/4) > >>

Benchtech:
Sorry for the influx of suggestions but once I get thinking then ideas keep coming.

I think SMF should flow more, it's hard to convey what I mean but currently I think SMF has to many page loads. It would be good to get instant feedback and autoupdating of threads. For example on forms, instant feedback with regards to passwords not matching etc. Also threads updating automatically without page loads and options in the moderation centre not being links but flowing more.

Sorry if this makes no sense, really hard to get my point accross.

Arantor:
While I appreciate where you're coming from, the fact is that there is no good way to implement that on PHP. You'd have to have requests made to the server on very regular intervals to check for new content. Even if 10 users are online, checking every 5 seconds, that's still 2 requests per second on average over and above what normally happens.

On this site, for example, there are typically over 1000 users online at any one time. Having each of them poll once every five seconds means that you'd have to be able to cope with 200 requests every single second, which adds literally thousands of database queries per second.

To achieve that you need to have a really serious server to cope with it, far beyond what most shared hosting solutions will provide.

Before we get into the suggestion of 'long polling' or 'Comet style' or even websockets, none of those work in a PHP based environment (except maybe if you're doing it through nginx/PHP-FPM and even then, experience of actually trying to make it work suggests it just doesn't)... because you implicitly have to hold the connection open on the server side to make it work.

Doing so on Apache (which is still the most popular webserver) means holding a PHP instance open for the entire time. Since that means an overhead of 8MB or so per PHP instance for the interpreter and the script being run, it doesn't take much before you get into needing a serious server to make that work - just for the PHP instances, 1000 users (like on this site) would require a machine with 8GB of RAM - just being kept in use, often idly, waiting for an update.

Even a much more modest setup, 10 concurrent users, say, that's still 80MB RAM just idling around, also far more than the average shared host is going to allow you to set up.


Unfortunately this is one of those 'nice in theory, hard to make work in practice' deals.

Kindred:
Additionally.... doing all that ajax-type stuff actually makes it nearly impossible for handicapped readers (like blind screen displays) to properly function.

Angelina Belle:
It would be possible to do partial-page updates following certain actions.  Everyone is thinking about social-networking type actions, right?
Frequent whole-page auto-updating could be very bad for large/active sites. But user-event-driven partial-page updates could actually save load on the server, if implemented properly.

I think it would be possible to switch between "classic" and "AJAX" to make access friendly for the handicapped.

Arantor:
Unless the partial page update is initiated by the user, it would be feasible - e.g. if the quick reply AJAXively updates the page. But, if it's a partial update that figures out newly updated posts, that's not going to save you anything and frequently would make it worse.

Navigation

[0] Message Index

[#] Next page

Go to full version