Http 304/rss

[Gayle]

I've been doing some experimenting with HTTP 304 (not modified) responses with the Mambo RSS. I have a modified version that checks the If-Modified-Since header from the client and if nothing in the feed has a modified or created date later than that then it sends a 304 response instead of sending the feed. If you are using RSS without the cache then a Last-Modified header will be sent with the reply so the client knows what to send back.

If you are using cacheing then it doesn't use the Last-Modified time, it uses an ETag. This is the MD5 sum of the cached file, if the MD5 sum of the cached file matches the If-None-Match header sent by the client then again a 304 is sent instead of the file.

More details and the files can be found at http://www.anothercrap.com/content/view/18/40/

Moving forward, I want to look and see if I can get Mambo to work with this as well. It could represent a very significant bandwidth saving on a busy site.

Comments anyone?

[pagerefiner]

Only a true nerd would appreciate this idea. This is done a lot with communication protocols and packet encapsulation schemes to improve bandwidth.

If the XML-RPC engine is still a possibility for 5.0, there could be other throughput advantages based on this general idea melded with some communication protocol ideas if it was optimized to allow servers and clients to poll each other to identify periods or high and low activity. Some packet queuing might need to take place, but the general idea might be bent a little to allow components to delay the performance of certain requested operations when a site was less busy in a web services environment. For example, polling another site to see if it was busy. The other site could reply with a busy or not busy acknowledgement. If busy, the requestor could queue the request for submission later. If not busy, the requestor could request an operation to take place. It would amount to creating a simple protocol that could be embedded in something like a SOAP message, developing the protocol to allow multiple sites to communicate and developing a simple queue or multiple queues to handle message packets. This would be like developing a conversational protocol where sites could talk to each other via RPCs. This might be a good idea for the RAMBO approach mentioned in older roadmaps where the Administrator location was isolated from the remote site.