On 16 Mar 2012, at 20:53, rene7705 wrote:
> On Fri, Mar 16, 2012 at 9:45 PM, Stuart Dallas <stu...@3ft9.com> wrote:
>> On 16 Mar 2012, at 20:36, rene7705 wrote:
>> > On Fri, Mar 16, 2012 at 9:29 PM, Stuart Dallas <stu...@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? 

> 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 Dallas
3ft9 Ltd

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to