   | |  | | ![]() I did say that the download should take place in the background. I highly doubt a single update would ever take a megabyte. I suppose there could be a low bandwidth option where it queries the server for an index of available information, but in most cases I doubt it would save bandwidth.
If each comment was the approximate size of a forum post, unless you're SL *cough*, that's typically not more than 1024 characters per post. With 50% compression rate (it's around that for text if I'm not mistaken), you can get 2048 characters in a single post for 1kb. 100 new comments would only be 100kb, which would be ~25 seconds on dialup.
Now if you want to include images, then that's a whole other story. It is an outright stupid idea, the very thought of including it in the guide (since I don't consider images to be part of the guide, but more of an optional supplement**) is I'll be nice terrible.
If you really want to save bandwidth, the background download can in theory be dropped to about 20-28 bytes per guide entry without compression (storage of location+entry# and possibly you could include size of text + size of extras for a couple bytes more). But the processing time on generating the index probably isn't worth it. You have to remember what needs to happen server-side as well as client-side.
From what you're saying, it sounds like for EVERY star (because I hope you don't mean planet) change you want to query the server for comments at that location. That, is going to be far worse than just a one-time update at the begining (imo, you should still be able to force an update to happen while you're playing), because there is the bandwidth required to make the query would be wasted essentially 100% of the time.
The average web host with say PHP scripts, I think time limits a script to 2 seconds, so all processing that the server needs to complete would have to happen within the 2 seconds.
The disabling GOES from people wanting to run a "clean" version, the time and bandwidth to convert a clean version of the game (with comments) to a sync'd version would be more work than it warrants.
I don't see your problem / your argument doesn't make sense to me.' | | | | I have another core principle (though it's more of a design principle):
| | | Assume any 3rd party library used is a security risk. | | | | | | This would be in addition to assuming our own code has a security hole, though if we use STL/Irrlicht's Containers it probably won't be too big of an issue, it'd just be using the containers in an unsafe way (i.e. write(&container[0], container.size()) is fast but unsafe). Stack corruption is mostly a non-issue now due to compilers being able to build stack checks/local buffer overflow checks into the code.
The justification for this design principle is that, the libraries we use would most likely be optimized to the point of near obfuscation. With that obfuscation, it's a whole lot harder to verify that there's no security holes. There's also the case where we use the library in an unexpected way thus causing a security hole to form. | | | | ** There's more than one reason why it should be optional, size is one; a security is the other remember the "recent" PNG bug? | |  | |  |
|
|
