 |
|
|
UER Store
|
|
sweet UER decals:
|
|
|
|
Activity
|
|
571 online
Server Time:
2024-05-09 11:12:01
|
|
|
 SoupMeister
       
Location: Athens, Greece
Gender: Male
 |  |  |  |  | Re: RSS feed
<Reply # 20 on 4/13/2005 7:59 AM >
|  | | | Posted by Kenshin
That doesn't really help much.
|
That's always the case, I'm afraid. 
It takes an immense global effort for a standard such as RSS to be established, and as usual it only takes one bad implementation to make it tumble.
Anyway, one page that describes this is http://blogs.law.harvard.edu/tech/rss#ltttlgtSubelementOfLtchannelgt. Look at the ttl (time-to-live) element.
We discussed this earlier in the thread, but one way to strengthen this on the server side is this:
At set intervals (perhaps as low as every six hours), the server goes through the database of forum threads and locations and generates static RSS files of everything. Since RSS is a tiny format, that's not too expensive on storage.
The web server (you can do this with Apache, I expect you can do this with IIS too) is told all these files are static and will not expire for six hours. It's also possible to tell the web server to cache/proxy these files in memory for that interval. Under many UNIX-based Apache installations, this isn't necessary. The operating system takes care of keeping regularly-hit files in memory itself (caching) and has a better algorithm for doing so than this. 
When an HTTP 1.1 browser hits the RSS (all of them, even old versions of Explorer that claimed they only talked HTTP 1.0), it also provides the date it last downloaded the file. The server checks the date against the date of the static file. If the static file is newer than the one on the client's side, the server tells it 200 ('here you go, buddy'), and sends the file.
If the static file is older, the server says 304 ('you've already got that, bog off') and doesn't do anything else.
If the RSS feed has a TTL of six hours, many RSS syndicators will honour it only hit the server every six hours. For those nasty ones that like to hit often, the server will have to deal with a static file, not a dynamic one (could be up to 10-20 times faster). It'll also be able to desist from sending, as static files can be made cache-friendly. The whole HTTP dialogue will be around 200 bytes long, compared to a few kilobytes long. Not a perfect world, but hey.
Besides, we're looking at something that will also authenticate -- and as such this will only be for the 'trusted' people. The feeds wouldn't be hit by thousands of non-users.
Sorry, I seem to have waffled again.
|
|
|
|
All content and images copyright © 2002-2024 UER.CA and respective creators. Graphical Design by Crossfire.
To contact webmaster, or click to email with problems or other questions about this site:
UER CONTACT
View Terms of Service |
View Privacy Policy |
Server colocation provided by Beanfield
This page was generated for you in 105 milliseconds. Since June 23, 2002, a total of 741131782 pages have been generated.
|
|
