AJAX Board Statistics

[Brandon C]

It would be cool to have AJAX Board Statistics, where (keeping in mind that all of the following would be AJAX):

• Whenever you viewed the Last Click or Member Name Online List, it would automatically AJAX-refresh it (without actually having to reload the page for those of you who don't know what that means) and you could see where the users and guests are without having to click update either.
• Whenever a new member registered, it would AJAX-refresh it to update the newest registered member at the bottom of the board.
• Whenever new posts and topics were made, it would AJAX-refresh it to update the increment the new post(s) into the post count for the board.
• Whenever a new day came around, it would AJAX-refresh it to show the new birthdays.

[Guest IAIHMB]

Now that you mention it I'm suprised that some of these features haven't been implemented already. In my opinion, if such changes were made they would have to be done unobtrusively. So many pages aren't available when JavaScript is disabled (The last time I checked that applied to damn near all of the administrative interface, the new user portals, all of the features in the options drop down menu, etcetera.). If they really are shooting for accesible, valid code in the next release they just can't hide their faeces with JavaScript. I think it would also be nice if the fixed all of the existing bugs (Some of which are well over a year old.) before adding more bloat, or they are just going to end up at the point of no return. Damnit Brandon C, you've inspired a rant. :P

[Strange_Will]

• Whenever you viewed the Last Click or Member Name Online List, it would automatically AJAX-refresh it (without actually having to reload the page for those of you who don't know what that means) and you could see where the users and guests are without having to click update either.
  How often? AJAX isn't 'intelligent' it still has to ask the server every x seconds. Or during a button click
• Whenever a new member registered, it would AJAX-refresh it to update the newest registered member at the bottom of the board.
  How often does this happen for it to matter? Not to mention again it takes ajax checking again and again
• Whenever new posts and topics were made, it would AJAX-refresh it to update the increment the new post(s) into the post count for the board.
• Whenever a new day came around, it would AJAX-refresh it to show the new birthdays.
  In case you're watching the board at 11:59pm and don't want to refresh when the next day comes around? :P Otherwise a waste of AJAX refreshes (or have AJAX wait till midnight... uh...)

[bfarber]

This would literally kill a large server. o.O Imagine 1000 people online - for AJAX to do something like this it would need to ping the server every x seconds - let's say 5. Every 5 seconds there are 1000 pings to the server just to update the 'latest registered member'?

I think this whole AJAX buzz is starting to get overboard. :rolleyes:

[K. T. Walrus]

One way to handle the load problem is to only do the AJAX when the user clicks an "update" button. That way, you don't have a full page reload but get a quick update of the info the user wants to see on the page.

I doubt 1000 people would be wasting their time clicking an update button to see new stats. Still, page updates without a full page reload can be a better experience for the end user and actually minimize some load on the server.

Note the "update" button could be set to be inactive for a couple of seconds (or whatever) to keep from being abused by a user.

[ZuCruTrooper2]

I kind of wish whoever did the JS / DOM scripting on IPB would do us all a favor and read DOM Scripting book... Would be so much nicer for everone

[MrWante]

I kind of wish whoever did the JS / DOM scripting on IPB would do us all a favor and read DOM Scripting book... Would be so much nicer for everone

That's such a helpful and constructive post!

[Guest IAIHMB]

I think this whole AJAX buzz is starting to get overboard. :rolleyes:

Isn't that the path Invision Power Board is taking? :P

One way to handle the load problem is to only do the AJAX when the user clicks an "update" button.

Hrm, that would cut down on bandwidth, but I would imagine people would just hit refresh and see everything that's changed (If you were viewing a topic and someone has responded, for example.). Then again, that could be a good idea. Just imagine, you're reading one of Nathan's posts, 10 minutes later you're at the end of the topic. You see something along the lines of "There are new responses.", and it allows them to be loaded on the spot. Once one new response has been made the checks would no longer have to be performed.

I kind of wish whoever did the JS / DOM scripting on IPB would do us all a favor and read DOM Scripting book... Would be so much nicer for everone

Let's just hope their PHP is better then their JavaScript. :P

[Mat Barrie]

I kind of wish whoever did the JS / DOM scripting on IPB would do us all a favor and read DOM Scripting book... Would be so much nicer for everone

Explain what in particular is flawed. Really.

[athlonkmf]

This would literally kill a large server. o.O Imagine 1000 people online - for AJAX to do something like this it would need to ping the server every x seconds - let's say 5. Every 5 seconds there are 1000 pings to the server just to update the 'latest registered member'?

I think this whole AJAX buzz is starting to get overboard. :rolleyes:

A large board (like signed) would have to use a not-standard setup to get things done. Like a seperate DB and webserver.

And who'd be so crazy to program something to all ping simultanously without some kind of caching. You could easily make the result of statistics written into some temp-file with a timestamp, and let the system check once every 5 second, each check makes a "lock" first so there will only be 1 query to the DB. Similar to the tasks built into IPB.

Anyway, I did not feel any need for statistics thingie so didn't made it, but there are ways to keep the "costs" low if I really wanted to have such changes.

I'm more afraid of the load that this IPB 2.2 is causing on this site. Before it was only a load of 1-2 and now the average is 4-5?

[Mat Barrie]

A large board (like signed) would have to use a not-standard setup to get things done. Like a seperate DB and webserver.

And who'd be so crazy to program something to all ping simultanously without some kind of caching. You could easily make the result of statistics written into some temp-file with a timestamp, and let the system check once every 5 second, each check makes a "lock" first so there will only be 1 query to the DB. Similar to the tasks built into IPB.

Anyway, I did not feel any need for statistics thingie so didn't made it, but there are ways to keep the "costs" low if I really wanted to have such changes.

I'm more afraid of the load that this IPB 2.2 is causing on this site. Before it was only a load of 1-2 and now the average is 4-5?

I think that perhaps that's due to the increased bandwidth requirements (more bandwidth requirements is more processing by the HTTP daemon software) that we have a higher usage here.

Oh, and as a reminder, File System access is MUCH slower than Database access. Databases already offer a level of caching on their own.

[ZuCruTrooper2]

Explain what in particular is flawed. Really.

There's nothing wrong persay, but there are slightly nicer ways of doing some things.

Unobtrusive javascript would be nice... Rather than using href="#" tags everywhere

If you're not familiar with something, don't shoot your mouth off. If you've read the book, you'll know what I'm talking about.

[ellawella]

Unobtrusive javascript would be nice... Rather than using href="#" tags everywhere

How does this affect the end user?

[ZuCruTrooper2]

It helps people working with the source and the skinning.

[ellawella]

It helps people working with the source and the skinning.

Personally, I find it doesn't make much of a difference.

[athlonkmf]

I think that perhaps that's due to the increased bandwidth requirements (more bandwidth requirements is more processing by the HTTP daemon software) that we have a higher usage here.

Oh, and as a reminder, File System access is MUCH slower than Database access. Databases already offer a level of caching on their own.

unless that file system is a 5MB RAMdisk setupped just for these kind of stuff.

[Guest]

I'm more afraid of the load that this IPB 2.2 is causing on this site. Before it was only a load of 1-2 and now the average is 4-5?

Given that the number of users online at any one time right now is about 4 to 5 times as high as usual, I'd say it's doing pretty well. ;)

[Michael P]

I think this whole AJAX buzz is starting to get overboard. :rolleyes:

Whats that...oh its a profile page full of AJAX :rolleyes: :P

All of the href="#" I see here and there is a little annoying, or links where its a javascript function call in the link, it would be nice if they had normal links there, which would fall back if javascript was disabled.

[ZuCruTrooper2]

Whats that...oh its a profile page full of AJAX :rolleyes: :P

All of the href="#" I see here and there is a little annoying, or links where its a javascript function call in the link, it would be nice if they had normal links there, which would fall back if javascript was disabled.

Finally, someone with a clue!

[UBERHOST.NET]

Finally, someone with a clue!

How's your forum software comin' along?

[ZuCruTrooper2]

I wasn't referring to IPB, I was referring to the idea that this javascript didn't affect end users.

However, this is more of a skin thing though, maybe IPB 3.0 will have cleaner code.

Don't take me wrong, it works fine now and there isn't a better solution, but there are ways that wouldn't assume the end user has javascript.

[bfarber]

A large board (like signed) would have to use a not-standard setup to get things done. Like a seperate DB and webserver.

And who'd be so crazy to program something to all ping simultanously without some kind of caching. You could easily make the result of statistics written into some temp-file with a timestamp, and let the system check once every 5 second, each check makes a "lock" first so there will only be 1 query to the DB. Similar to the tasks built into IPB.

Anyway, I did not feel any need for statistics thingie so didn't made it, but there are ways to keep the "costs" low if I really wanted to have such changes.

I'm more afraid of the load that this IPB 2.2 is causing on this site. Before it was only a load of 1-2 and now the average is 4-5?

Actually, the load spiked during the first release (with all the traffic), and right now a bug is preventing the server load from updating within IPB. As of the time 2.2 was installed, it's said 4.45 ;) In 2.2 the server load is cached and only updated in IPB every 10 seconds - for whatever reason that isn't happening here (but works fine locally).

I assure you - I've personally spent countless hours profiling the php code and tweaking things as was possible. 2.2 supports memcache and eaccelerator for example, and supports MySQL 5. Even if you don't have MySQL 5, if you have the mysqli php module installed IPB will make use of that rather than the older mysql client.

2.2 really should run a bit smoother than 2.1.

I wasn't referring to IPB, I was referring to the idea that this javascript didn't affect end users.

However, this is more of a skin thing though, maybe IPB 3.0 will have cleaner code.

Don't take me wrong, it works fine now and there isn't a better solution, but there are ways that wouldn't assume the end user has javascript.

Realistically, 98% of end users have javascript capabilities - and dynamic websites that don't solely rely on the backend require javascript to handle some of the flashier things on the front end. I know all about # in href's - that doesn't mean there's always an easy and worthwhile way around using them though. I've actually yet to come across someone who had problems with the links to be honest. If you aren't using a browser that supports javascript, I'd say it's about time to upgrade.

That said, you should see some of the javascript Matt's done for 2.2 (i.e. the profile page). Blows my mind looking at it (and makes me want to cry when we get bug reports regarding it).

[ZuCruTrooper2]

I'm sure most users do have Javascript capable browsers, but some people are still very nervous regarding it. It got a bad rep a long time ago, and I know a lot of people who still are weary of it.

[Dlf]

Suggestion: Admin option (somewhere in the ACP) to set amount of time board waits to updates states (minium of why not 1 hour, max 1 week).

Suggestion#2: Admin option to choose where the update occurs (so to not strain the server).





Some of the mods for 2.1.x are very impressive, like click & hold to edit cat/forum title/description. ARMY CORE mod, doesn't show all the options unless you "install" them, or you click the right link in the ACP. "Remove" components from view. Very nice.

[Guest IAIHMB]

Realistically, 98% of end users have javascript capabilities - and dynamic websites that don't solely rely on the backend require javascript to handle some of the flashier things on the front end. I know all about # in href's - that doesn't mean there's always an easy and worthwhile way around using them though. I've actually yet to come across someone who had problems with the links to be honest. If you aren't using a browser that supports javascript, I'd say it's about time to upgrade.That said, you should see some of the javascript Matt's done for 2.2 (i.e. the profile page). Blows my mind looking at it (and makes me want to cry when we get bug reports regarding it).

The