I was willing to put up with FProxy up till now, and passively accept it as
the 'Official Freenet HTTP Interface'.
But three things have convinced me that it needs to immediately take Tim
McVeigh's place on death row:
1) Performance - I tried streaming an MP3 off Freenet, and ended up with
ears full of stutter and gibberish.
In contrast, a native binary version of FProxy, using FCP, delivered
blissfully clean uninterrupted audio.
I know my machine is not latest tech, but an Athlon 750 with 256MB RAM
7500RPM UDMA-66 disks is not exactly primitive.
2) URL Molestation - when pasting a freenet URI into the gateway page's
'Request' form, the ridiculous encoding of slashes into %2F totally destroys
relative links within freesites. This problem does not occur with native
binary FProxy implementation.
3) MIME Type Mis-Handling - when browsing
'freenet:MSK@SSK@argargarg/sitename//', FProxy doesn't send any
'Content-Type: text/html' header back to the browser. This causes browser to
mistake the default freesite page as something requiring download rather
than display. It also trips the anonymity filter. Again, no prob with native
binary.
I suggest that a strategic decision be made to switch to native binary
implementations of FProxy.
On Windows, no problem. Ditto for Mac, since binaries are completely
portable across installations of the same class of OS.
On Linux, might require a 'make'. But so totally worth it.
I know that some of my points above are completely trivial to developers.
But to less skilled users, these quirks are easily severe enough to alienate
a large percentage of people who would otherwise contribute much needed
nodes/bandwidth/storage.
Freenet still has a lingering reputation for requiring its users to be
developers with crypto skills, or at least patient and persistent
power-users.
Overcoming issues like these will go far towards shaking off this bad rep.
David
_______________________________________________
Chat mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/chat
