Simple fix for the safari problem: don't include active links in the front page...
This can be done by checking the user agent string. Ian. On Thu, Mar 6, 2008 at 5:49 AM, Matthew Toseland <toad at amphibian.dyndns.org> 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. > > > > 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/ > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- Email: ian at uprizer.com Cell: +1 512 422 3588 Skype: sanity
