Matthew Toseland schrieb: > 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-
Sorry for jumping in.... Can of worms. You shouldn't even consider manipulating any data or trying to find out wich proggies a user uses along with Freenet. As soon as so. finds out Freenet is sniffing their os or is performing strange hacks Freenet will be dead. There is nothig you can do to keep a user from doing something stupid in FProxy as long as FProxy needs ie, ff, whatever. Even my notepad has the strange habit of phoning home when I throw certain control chars at it. You should separate client and node stuff better. FProxy is a client like any other client. If it sucks, kick it ...or leave a note to users. ...and leave it up to client devels to come up with somthing that works. Everything else is taking devel time from me ...the client. Juergen
