RSS feeds of character reports

[Spillages]

It'd be nice to have RSS feeds of each of our characters. or even atleast or accounts in general.

[Rossato]

Duplicated and rejected suggestion, but I like it.

[Solfius]

I'm not familiar with RSS apart from live bookmarks through firefox, but is there anyway to authenticate users, so that you can only access your account/characters?

A quick google suggests it's possible, but not widely used, and there may/may not be off the shelf packages available for it, which means a custom solution would have to be researched and coded.

[Spillages]

It's a very easy and simple code to add in and doesn't use up much resources that I am aware of. But then again, I don't know any of Cantr's code so I have no clue if it'd work or not.


Edit, as far as authenticating users i'm not sure on that. but even if you were dumb enough to let out the hash for your feed they'd still need your password to log in and screw with you charries. So, unless someone knows the code to figure out your hash, you don't have to be afraid fo anything bad happeneing, in which case if soemone is smart enough to get it, they're probably smart enough to get your password also.


Second edit:
http://www.cantr.net/forum/viewtopic.php?t=13832
Chris explaining why it wouldn't work.

Now, here is my opinion, Run the RSS not off of each individual event for each char, but only have the feed show charries for each player that are lit. It woudl require alot less resources and woudl effectively get the job doen that many have wanted for a long time.

[Money]

But with the lag right now do we really want to add this on to an already large problem? I know it doesnt take up much resources but every little bit counts. Also since ProgD is so busy do we really want to put more on their plate?

[Spillages]

Yes, there is also the possibility of it reducing lag as alot less people would be rushing in and otu of cantr only to see their charries are still dark. This way, they can avoid the site until they get a message on their screen sayign that soemthing has happened.

[Solfius]

ok, so

300,000 events per day
and
6344 characters according to my latest turn report

That's, on average, 47.289 (3dp), events per character per day.
Which is roughly 1 event ever 30 minutes for every character in the game

So, to implement this, you'd have to update 6344 feeds at least every 30 minutes to keep it reasonably current, and that's assuming events only occur every 30 minutes, which is obviously not correct.

Assuming that the whole process, for each feed, takes 0.1 seconds (which is a guesstimate based on a rough average of the page load for the index page based on around 10 or so refreshes), that's 634.4 seconds to execute the process, every 30 minutes, on top of everything else going on.

So, to summarise. You'd have a process executing every 30 minutes that takes approximately 10 minutes to complete, plus everything else the server is trying to do.

So, this process would be running a third of the time, assuming my assumptions were roughly accurate.

I think I have to agree with the original decision. The performance doesn't justify the benefit.

[Spillages]

No, i'd have to disagree,

0.309 seconds taken, 60 queries executed (SQL took 0.140 seconds - 45.3%).

That is alot of stuff going on when a page loads. An RSS feed is only updating less than a byte of data when a page is a few hundred kb

[SekoETC]

Also it could ignore sneezes and such and only show talking and people attacking people.

[Money]

Another question is, Does ProgD have the time to implement this?

[Solfius]

It's not the amount of information, but the processing required to generate it.

For example, to update a feed showing if a players characters have new events, you have to:

firstly, ensure only the correct player can access that feed - we don't want other people knowing when your character have new events as it may allow some form of cheating

To do that, we need to process a login to check the user's credentials (1 query + processing).

After establishing the user is who they say they are, we need to identify the characters attached to their account (1 query plus processing)

Then, for each character, we need to check to see if there are new events. How to do this depends on the implementation for events, but it's at least 1 query, to search the events table for relevant events, and possibly a second query, to see when the character was last checked, and then some processing to see if anything new has happened since then (it's unlikely that the time the character was last checked will be stored in the events table, so I'm going to assume 2 queries + associated processing)

Then we can update the feed to show if new events have occurred, which entails, most likely, creating an XML file containing the feed, which won't require database access.

So, that gives us 4 queries, and processing resulting in a small page being constructed.

the Login Page only has 4 queries, and is a small page (the html file, excluding graphics and other extras, is 8kb) so perhaps that makes a better approximation to the amount of processing RSS feeds would require.

So, I've loaded the login page 20 times, with these load times:
0.199
0.132
0.108
0.106
0.167
0.056
0.31
0.056
0.119
0.055
0.062
0.055
0.105
0.055
0.11
0.126
0.146
0.122
0.077
0.069

Note, I did this also without loading images, javascript, etc, and it didn't make a significant different, a few millionths of a second faster I think

The average processing time is 0.11175 seconds, which is pretty much what I assumed in the first place.

Also, as the bulk of the processing is determining if there's anything to update, omitting events such as sneezing won't make much difference as the script still has to query the whole table to see if there's anything that will trigger an update.


And finally, how often do you expect this to run? so far, I've assumed every 30 minutes with an execution time of 10 minutes. Are you really going to wait 30 minutes to see if anything new has happened when you can simply log in right now and find out immediately?

If you run it more often that about 15 minutes it'll soon start to overlap and lag, similar to what the existing processes do fairly often.

[Spillages]

Your making it way more complicated than it needs to be, have it run off of each player instead of each character. I tried to explain it a bit ago but seems I was misunderstood.

I'm guessing, and this is only a guess as I don't know what cantr code is like but my assumption is that a character is either true/false to being lit up and all it the feed needs to show is that true/false data, nothing more. Just enough to show that you should log in and check your char. if true then a link to a login page requiring your ID and Password and then goes directly to the char. if false then no links will be in your feed.

So, it's already processing when it lights up a char, so why not just have it publish to the feed as well?


EDIT: and I don't believe we're allowed to link to the login page.

[Solfius]

Your making it way more complicated than it needs to be, have it run off of each player instead of each character.

So a list of what characters have new events for your account.

To find out what account needs to be shown in the feed, we need to authenticate the user, that is, we need to process a login. The alternative is an RSS feed that shows all 6000 or so characters. Not good.

I'm guessing, and this is only a guess as I don't know what cantr code is like but my assumption is that a character is either true/false to being lit up and all it the feed needs to show is that true/false data

This will be calculated when the script is run. e.g. only when the character page is loaded. It will be based on a query, not a stored variable, because the variable will need to be kept up to data (more queries and processing), whereas a single query when the page is displayed will be up to date.

So, it's already processing when it lights up a char, so why not just have it publish to the feed as well?

But where does this variable come from? It has to be calculated from the database, either when the script executes, or in advance and stored.

Storing it makes no sense because it'll need to be kept up to date (and will have the same performance issue as updating the RSS feeds and will require more database queries to store and recall), so calculating it when the script executes is the best option.

Just to make it clear, the true/false value is calculated as part of the script that loads the character page where it is needed, not stored in a general variable.

This is because the only way to store the variable is in the database, so keeping it up to date is very difficult (effectively, the same issue as processing the RSS feeds) so calculating it once when required is far more efficient.

[Arlequin]

You don't need to update a RSS feed that isn't being requested.

On request, it checks if the cached version is more than 30 minutes older, then generates it. Otherwise it serves the cached one.

Therefore, feeds that never are requested, never are updated. You'll need all users updating the feeds each 30 minutes, 24/7, to hit the maximum load.

But then:
a) I'm not sure how well RSS's under authentication would play with RSS readers.
b) They'll need to include the Ads that help pay for Cantr.

[Solfius]

You don't need to update a RSS feed that isn't being requested.

That sounds more viable, but I can't find anything on triggering a script in this manner.

Because RSS is based around .xml files, and the server won't parse .xml files for php by default.

Although, it can be done by modifying .htaccess on the server (see: http://www.desilva.biz/php/phpinhtml.html and replace .html with .xml)

This would allow the .xml file for the feed to be processed by PHP and thus only query the database when the feed was requested.

This would only be as burdensome as logging in and loading the character page (possibly less so, as less information is being retrieved).

This approach solves the performance issues I wrote about above.

That only leaves the issue of authentication. That's possible, via HTTP and SSL, but as I don't know how those technologies work regarding authentication I can't say much else.

But, based on the credentials supplied, the php script can return the correct information for that user, so long as it uses the same user ID and password used in the game.

EDIT: information on authentication in RSS:
http://www.rassoc.com/gregr/weblog/2003 ... ntication/
http://labs.silverorange.com/archives/2 ... privaterss