I really think option 2 is the by FAR the most user friendly, for quite
a few reasons-
1) Software shouldn't be ill-behaved. I'm a large advocate of and for
Freenet, and even I get quite annoyed when freenet alters Firefox by
creating a new profile. I understand the rationale, but one software
package shouldn't modify the others on your machine. This is in part a
trust issue- Imagine the arguments on Slashdot if the newest iTunes
update added a Firefox profile for browsing Apple specific sites.. One
software package shouldn't be modifying others.
2) Creating a firefox profile doesn't work if Freenet isn't installed
locally. Freenet runs as a daemon, which is very convenient to connect
to remotely.. Since freenet requires a permanent connection to be
helpful, I prefer to run it on an old server in the closet, or hosted at
a Datacenter; Both of these optiosns work fine with Option 2, but with
option 1, I get the old-style, degraded experience.
3) Not everyone uses Firefox. I know, they should. IE has bugs, etc,
etc. But Opera still has quite a few users, Safari is the default on the
Mac, and Chrome is a growing alternative on Windows. It shouldn't be a
requirement that users use a specific browser to access Freenet
Your point about Browser History can be addressed by Noting that users
may want to use the "Privacy Mode" feature of their browser, if it
exists. Safari and Chrome have this feature, and Firefox is adding it in
the next revision. While the Privacy mode is active, no history is
saved, and the cache is wiped.
The connection limit is going up across the board.
https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4
Firefox 2: 2
Firefox 3: 6
Opera 9.26: 4
Opera 9.5 beta: 4
Safari 3.0.4 Mac/Windows: 4
IE 7: 2
IE 8: 6
It's important to note, however, that the delay is not caused in going from
fproxy to the browser.
The delay caused because Freenet takes a long time to request from the network.
A "Loading" page is necessary here regardless.
Further, since, IIRC, freesites are submitted as compressed entire sites,
requesting index.html will also pull in the images, etc.
This means that by the time any of the site loads, fproxy should already have
the rest of the site in cache, so the browser limit isn't the issue.
I think the current situation is probably good enough, if the loading screen
were in place. The browser-in-a-browser is the best option of the three, but
still seems overkill.
-CPD
