KT Walrus Posted July 29, 2010 Share Posted July 29, 2010 I'd like to see all lists and topic displays utilize a 1 to 2 MB local database if the user is browsing with an HTML5 browser that supports local SQL databases. There are a lot of possibilities to lesson the load on the server (not to mention that retrieving data locally and formatting the page would be very fast from the users point of view). Much like HTTP servers can keep a unique code associated with a file and tell the browsers they can use the cached version of that file, the IPB JS can do something similar using the local database as a cache. I would try to cache forum lists and topics/replies. This change might involve storing enough of the skin templates (converted to HTML templates that local JS could manipulate and process) to display portions of a page. Anyway, since many browsers now support HTML5 and local SQL databases, IPB might want to evolve in such a way to take advantage of this feature to off-load processing/page load to the user's browser and away from the PHP server. Pages that can load from a simple cache validation AJAX call should be very fast to load. Note that my iPhone has an HTML5 browser and this might even reduce the amount of data transferred to the mobile device and the time that takes. Link to comment Share on other sites More sharing options...
.Peter Posted July 31, 2010 Share Posted July 31, 2010 I didn't realize HTML5 had the capability to do that. That's brilliant. That would be AMAZING for a forum. Link to comment Share on other sites More sharing options...
KT Walrus Posted August 2, 2010 Author Share Posted August 2, 2010 I looked into this a bit closer. The Web SQL Database standard has been separated from HTML5 and seems to have hit a stall in the standardization process since all the early adopters of the standard are based on SQLite. Apparently they need two independent implementations to make a standard and no one has stepped up to the plate yet. Still, IPB could take advantage of this feature in Chrome, Safari, and Opera, but FireFox has gone a different way. There is a Web Database draft standard called Web Storage that provides client side storage (basically using get/set operations to associate a key with a value). This standard is not stuck like the Web SQL Database standard and is supported by IE8, Firefox 3.5+, Safari 4+, Chrome 4+, and Opera 10.50. The Web Database while it only has get/set/remove operations, would be sufficient for IPB to "cache" data for a page on the client side (in the browser). This could be sufficient for offloading some part of page creation by cacheing the list of items locally and simply checking whether the "cache" with a given key is still valid (meaning no data has changed from the value associated with the key), or returning the new data to be saved with a new key/value pair. This could eliminate some load on the server and speed up page loads (especially on mobile devices that support this feature). Link to comment Share on other sites More sharing options...
Anthony. Posted August 2, 2010 Share Posted August 2, 2010 I'd like to see all lists and topic displays utilize a 1 to 2 MB local database if the user is browsing with an HTML5 browser that supports local SQL databases. There are a lot of possibilities to lesson the load on the server (not to mention that retrieving data locally and formatting the page would be very fast from the users point of view). Much like HTTP servers can keep a unique code associated with a file and tell the browsers they can use the cached version of that file, the IPB JS can do something similar using the local database as a cache. I would try to cache forum lists and topics/replies. This change might involve storing enough of the skin templates (converted to HTML templates that local JS could manipulate and process) to display portions of a page. Anyway, since many browsers now support HTML5 and local SQL databases, IPB might want to evolve in such a way to take advantage of this feature to off-load processing/page load to the user's browser and away from the PHP server. Pages that can load from a simple cache validation AJAX call should be very fast to load. Note that my iPhone has an HTML5 browser and this might even reduce the amount of data transferred to the mobile device and the time that takes.Would you know if xenforo.com is doing this ? ... I believe I read they coded using HTML 5 :rolleyes: Link to comment Share on other sites More sharing options...
Biker.GA Posted August 2, 2010 Share Posted August 2, 2010 While this may look great on paper, realistically, I see a LOT of users complaining about initial load times for forums using this method of caching. There are a lot of folks still using dialup and subpar DSL connections that would not handle such a load nicely. This is something that would have to be activated on a case by case basis by forum administrators. Link to comment Share on other sites More sharing options...
KT Walrus Posted August 2, 2010 Author Share Posted August 2, 2010 While this may look great on paper, realistically, I see a LOT of users complaining about initial load times for forums using this method of caching. There are a lot of folks still using dialup and subpar DSL connections that would not handle such a load nicely. This is something that would have to be activated on a case by case basis by forum administrators. Client side caching would speed up "dialup and subpar DSL connections". And, JS performance has improved a great deal with Web 2.0 being ubiquitous. Note that IPB already does a little client side caching in using Cookies. The difference here is that all cookies are sent to the web server on each page request while the Web Database is only available on the client side (through JS). But, IPB doesn't attempt to cache lists/threads that are often simply the same as the last time the user loaded the page. Obviously, any client side caching would be configurable just as the current server side caching is. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.