On Thursday 06 March 2008 11:49, Matthew Toseland wrote: > On Wednesday 05 March 2008 22:13, Colin Davis wrote: > > As a ignorant user, I think that's as a general principal, Freenet > > should try to be as browser agnostic as possible.. > > > > 1) Firefox may not be the dominant browser down the line- Freenet > > shouldn't constantly chase the tale of different browsers. > > 2) Most users don't use Firefox currently. Most general web users still > > use IE or Safari, depending on what their PC shipped with. > > Both IE and Safari have *MAJOR* problems with Freenet. Safari waits for all > the images to be loaded before even attempting to render the page; IE > autodetects HTML even when it is told that a page is plain text (which is a > major security breach as an attacker can then send unfiltered HTML including > webbugs and scripting). Therefore neither is appropriate for Freenet. I'd > seriously consider a browser plugin at this point, but it'd probably need to > be a full browser fork and there's no way we have the resources for one. > > > 3) Freenet is a server process, and optimization shouldn't suffer unless > > absolutely necessary over a network. > > 4) It's considered "impolite" to modify settings in programs that you > > didn't ship. You don't want Freenet to get a reputation as a invading > > your system. > > True enough, but the alternatives are: > - Doing nothing. This sucks. > - Telling the user to change the settings manually. But if they do, their > browser will be detectable (with a few false positives) as having been > modified to work better with Freenet. > - Creating a Firefox profile for Freenet, and using that. This may result in > the user when they open a browser normally being asked to select a profile.
Actually there is one problem with this: when you load firefox without any arguments, it uses the previous profile. :( > > > 5) I think there may be other ways to fix the problem. > > > > One of the way to get around the persistent connection limit is to > > connect to Freenet on multiple hostnames, or DNS addresses. > > For example, if Freenet is running on the local system, the URLS on the > > page could be given multiple ways. > > Doesn't work on a LAN. On localhost, we could conceivably listen on 127.0.0.1, > 127.0.0.2, 127.0.0.3 etc. Rewriting URLs as absolute links referring to > different hosts is posssible if we're on localhost (which we can tell from > the IP on the other end of the connection). So you have a point to some > degree. Although the whole purpose of having a higher global limit is to > leave some slack for other servers, and we'd break this, so if the user has > other browser windows open they may not work. > > > > For example, if we had a page of activelinks, freenet could return them as: > > > > http://127.0.0.1/CHK/foo1.png > > http://127.0.0.1/CHK/foo2.png > > http://localhost/CHK/foo3.png > > http://localhost/CHK/foo3.png > > http://192.168.1.15/CHK/foo5.png > > http://0.0.0.0/CHK/foo5.png (Linux only) > > > > By varying the URL, you increase the number of connections to the max > > per browser, rather than the max per server. > > > > See: > > > http://www.ajaxperformance.com/2006/12/18/circumventing-browser-connection-limits-for-fun-and-profit/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080306/fdce69ac/attachment.pgp>
