Re: Got HTML5 History API + caching LICKED, I think, <grin>

On 16 Mar 2012, at 20:53, rene7705 wrote: > On Fri, Mar 16, 2012 at 9:45 PM, Stuart Dallas <stuart@3ft9.com> wrote: >> On 16 Mar 2012, at 20:36, rene7705 wrote: >> >> > On Fri, Mar 16, 2012 at 9:29 PM, Stuart Dallas <stuart@3ft9.com> wrote: >> >> On 16 Mar 2012, at 18:57, rene7705 wrote: >> >> >> >> > Hi Folks.. >> >> > >> >> > I could waste a lot of text on what I've accomplished during the last >> >> > months, but the easiest thing is if you have a (another) look at (the >> >> > source of) http://mediabeez.ws >> >> > >> >> > I think you'll like my opensourced work :) >> >> > >> >> > Feedback is appreciated. >> >> >> >> I'm also having trouble downloading the ZIP file (Chrome 17.0.963.79 on OSX - >> >> not that the browser will have anything to do with this problem at all). The download starts, gets >> >> to a few MB and doesn't get any further. >> >> >> >> And 52MB? Since I can't actually see what it contains it's hard to >> >> judge, but right off the bat... is your artwork necessary for the thing to work? What external >> >> libraries are you using? >> >> >> >> Just from looking around the site there are a few things that jump out... >> >> >> >> * The dropdown menus are incredible jittery, certainly nowhere near >> >> production-ready. >> >> >> >> * The background image gets squished according to the dimensions of the browser >> >> window. >> >> >> >> * Your homepage weighs in at massive 2.6MB. Nuff sed! >> >> >> >> I suggest you take the focus off the way it looks and concentrate on what it does. >> >> Tabs with animated backgrounds remind me of websites from the late 90s. You may have developed an >> >> incredible framework here, but I don't know because it's buried under >50MB of other >> >> stuff that I almost certainly don't care about, and that's before I've even been able >> >> to download it. >> > >> > ok.. >> > >> > That being unable to download the zip file correctly is something I'll take up >> > with my hosting provider tomorrow. >> > I've downloaded it in full and opened it OK in winrar just now, btw. >> > >> > The zip-file is created with winrar on windows 7, and according to Floyd Resler has to >> > get it's extension changed to .rar, then decompressed with Stuffit Expander. Also something to >> > look into soon, btw. >> >> That would explain why every zip decompression utility I've tried thinks it's >> corrupt. >> >> > As for my menu being jittery, it's not jittery on any of the windows browsers I >> > tested. >> > And I have no mac-book available to me, not even from friends and family who are all >> > on windows (on my recommendation btw ;) >> >> Are you ready for the shocking truth... not every computer in the world runs Windows, so >> unless you've developed this purely for the friends and family you've convinced to do so >> you may want to rethink your approach to testing. >> >> > As for my files and homepage being Huge, yep, it's made for the future or current >> > fast internet connections. >> > Frankly, size reduction is not on my agenda. I'll wait for the nets to become >> > faster still. >> > And the server should spit it out at 2MB/s at least.. >> >> That may be so, but when my 100Mbit/s connection finally managed to download the file it >> took about 4 minutes, which is nowhere near 2MB/s. Your homepage takes 7 seconds to load - >> that's unacceptable in the real world, especially when you're talking about a server >> that's (and I'm only guessing here) not under heavy load. >> >> Anyway, your comment about waiting for the nets (sic) to catch up so it can cope with your >> bloat has convinced me to not bother looking any further into your project, but I wish you the best >> of luck with it (you're gonna need it). > > Okay, I don't wanna get into an argument here.. Shame, because I'd love to see you try to defend a position that promotes wasting resources "just because they're there." This is not a new thing - ever-increasing computing resources have always led to this short-sighted view in the inexperienced, but trust me when I say you'll regret it when you're paying for the bandwidth being used by thousands of people simultaneously using a site that's using your framework. Why do you think other libraries such as jquery recommend minifying their code before deployment, and then serving it via gzip? Every bit and byte counts, especially as you scale up. Anyway, I'm not trying to get into an argument (it's rare that I do), but I do recommend that you take in what I've said on this issue. The size of the data you're sending down the pipe matters if you want your library to be used for anything serious, and no amount of artwork or pretty pictures will distract anyone for long. > Rest assured, all the javascript for my animated widgets combined is about 25kb. Good for you. You might want to produce a download that doesn't include the optional stuff so you can show how small it is, and provide examples that show off what it can do using just that code. Incidentally, a little over 2MB of your homepage is the logo. 2MB for the logo? Seriously?? > The artwork for simple animations is about 100kb per button/menu-item theme. 100kB is not a simple animation, that's a mini-movie. > The fact that I demo how to put video on a button and thus end up with nearly a dozen button > themes that are about 2MB each, is just taking advantage of the fast links that are available in > much of the world. Make them a separate download. Not everyone is using a "fast link" and even those of us who are may not care about those themes, so give us a choice as to whether we download them. I certainly don't care about scenejs, yet it has decompressed to 19MB! > About me testing only on windows, you're right about that and I'll see if I can do > something to improve my testing regime. For now i'm dependent on your patience and bugreports > tho. That's not what you said, you basically said that you've tested it on Windows and don't care about anything else. Please don't take this as harsh criticism, but if you're developing a library for other people to use, you need to consider the environments in which they're likely to use it. If you don't have the capability to develop/test your library on different systems you need to foster a community around your library that can test for you and ideally provide patches to fix bugs. I know testing on OSX can be an issue due to prohibitive cost, but there's unlikely to be a good reason why you can't test on Linux. > And I had no idea winrar made such crappy zip files, I'll look into a replacement very > soon. Winrar did its job and made a rar file. Did you change the extension to zip? The best compression utility I've found for Windows is 7-zip, but I haven't used that OS for a while so I dunno if it's still the best. I took a quick look around your code and I saw some scary stuff in there. Taking lib_fileSystem.php as an example brings up the following issues... * In the fgetsr function you open the file for reading and writing despite only needing to read from the file. * In zipExtractUnix you pass arguments onto the command line without escaping them. You also assume that there is a command named "unzip" on all platforms, where such a utility does not natively exist on any platform that I'm aware of (possibly some Linux distributions I'll grant you, but they're the exception rather than the rule). * Not entirely sure what evalDate is supposed to do (function-level comments would be useful) but it's passing variables into eval without any checks on what they contain. Rule of thumb: if you think eval is the answer you're asking the wrong question. * In getFilePathList you're using evalDate, so now I know what it's for, and you're definitely asking the wrong question. * Your readIniFile function appears to be doing the same thing as PHP's parse_ini_file function. * There's a PHP function for renaming files, which will let you make your renameFile function safe (it's not currently safe because it's another example of not escaping arguments on a command line). * Strangely you then use PHP's rename function to rename a file in moveDirectoryStructure, so you're clearly aware of it. I've probably missed stuff because this was a quick skim, and I've ignored stylistic preferences that bug the hell out of me, but despite those caveats there are some very serious, and pretty basic, security issues here. I hope you find my feedback useful once you get past my sarcastic tone. I tried to control it once, but it wasn't pretty and it didn't end well! :) -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/