lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

... and follows more retarded logic..
It's not a bug, thus cannot by definition be 'fixed', we're talking about a trivial change here.
The goal is to have it work with as many servers as possible, and if 'PASV' does that more than 'pasv', who cares?
This change doesn't make luasocket more or less conformant, it doesn't introduce a 'new bug', the only downside is someone needs to do about 7 seconds worth of editing, and the upside is it will work with servers who are anal about this.
We're not talking about gay rights or abortions, give it a rest already, you wont change all the worlds ftp servers.. They've existed for well over 30 years, so no, people evidently do NOT follow specs, and good look to you on your utopian plans for the future 
if you think you can change that.


ketmar wrote:

On Fri, 07 Nov 2008 18:16:58 +0100
Stefan Sandberg <keffo.sandberg@gmail.com> wrote:


We've already established that 'pasv' is no more correct than 'PASV',
so it not a bug.

and so ith shouldn't be 'fixed'.
If 10% of all ftp servers fail to follow specs, you want to prevent luasocket users access to them because of some principle? 
nope. LuaSocket dox can mention this fact. but there are no sence in
'fixeing' a perfectly correct implementation.


If something as trivial as this, with no negative side effects, fixes
an evidently existing issue, regardless of who created the issue in
the first place,
why even argue about it?

'cause 'fixing' non-existant bugs is actually creates TWO bugs istead
of reducing this number to zero. the more we 'fix' such non-broken
things, the more authors tends to ignore RFC. just look at w3c standards
and to the current situation in http/css world.

the *broken server* should be fixed, not the *correct client*. this can
create problems in shrot term but will reduce problematic cases in long
term.

*never ever 'fix' non-broken things. or the really broken things will
remain broken forever.* it's a very simple rule.


luasocket is a tool, like most other libraries, just solve the issue
and be done with it, you're engineers!..

and i agree that issue must be solved. by the server author, not by the
author of LuaSocket. or we can just throw out RFCs -- who actually
needs the specs that nobody follows?