On Wednesday 31 December 2008 14:48, Florent Daigni?re wrote: > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-12-31 14:23:01]: > > > #1: 41 votes : release the 20 nodes barrier > > > > "most of the users nowadays have a lot of upload-bandwith available. Myself > > has about 3Mbits upload, but the limit to connect to not more than 20 nodes > > results in about 50kb/s max. Please release the limit or use a dynamic system > > that offers more connections if the node has a high bandwith upload limit > > (scaling). Thx" > > > > I'm not sure what to do about this. The original rationale for the 20 peers > > limit was that we didn't want to disadvantage darknet nodes too much on a > > hybrid network, since they will not often have large numbers of peers. > > Combined with experience on 0.5 suggesting that more peers is not always > > better, a security concern over over-reliance on ubernodes, and the fact that > > we should eventually be able to improve bandwidth usage through better load > > management. However, there's a limit to what we are able to achieve through > > better load management, and it's a difficult problem. > > > > Thoughts? > > Nah, the original rationale was : > - "it must be consistent with the default bandwidth limit" > - It has to be homogeneous network-wide (result of some > simulation work iirc)
I'm not sure there was a theoretical basis for this? We don't want to be too reliant on ubernodes, but I don't remember there being any theoretical problem with some nodes having 40 peers and some having 10. We should ask a theoretician. > - A low value will make flow analysis harder and might help with > sneaky QoS network policies May be true. > > As far as I know nothing has changed regarding any of those points: why > should we change it? > > > #2: 38 votes : one GUI for all > > > > "For new (non-technical) users it may be very difficult to understand what > > they really need, how to do it and how to use it. > > > > The entry point of an application plus its visible style, the user interface > > aso. are playing the biggest role for acceptance nowadays. > > > > Therefore there may be the need of a GUI (I imagine one written in XUL, so it > > runs on all plattforms, easily extensible, aso., we are already using a > > custom firefox profile so why don't write our own user interface?) that > > provides all mechanisms that are available throughout the freenet network. > > File sharing, messaging, flogs, identity management and others." > > > > IMHO part of this is simply an endorsement of the current not yet implemented > > policy to move everything possible into the web interface. A well designed > > web interface could be easy to use and responsive. There is an argument that > > we need an actual XUL app ... but this will be a huge amount of work to > > little benefit IMHO. > > > > #3 tied: 33 votes : show a progress screen when loading a page (Filed by me) > > > > "Is this a good idea? Would it make Freenet more user friendly if it didn't go > > off into limbo while loading a link?" > > > > This is planned. IMHO we should implement it before releasing 0.8.0, it would > > be a significant enhancement even without real time updates with javascript > > support, provided it is not shown unless we have reason to believe the > > download will take more than 5 seconds. It is especially interesting if > > combined with some new content filters for e.g. audio files. > > That's maybe 2 hours of work to do! Should be done already. Agreed, it should be done soon. > > > #3 tied: 33 votes : add a 'pause' feature > > > > "It would be cool if it was possible to 'pause' a freenet node. I mean, stop > > all network traffic, warn peers that we are on pause, but keep the node > > alive. > > > > That would allow short downtimes for online gaming without the hassle of > > having to restart the node and wait for it becoming usable again." > > Like if gamers were going to use the feature... They will shut the node > completely down anyway because that will allow them to reclaim a dozen > of megabytes of virtual memory (and there is no hope of trying to > explain to them that they shouldn't care about it because it's gonna be > swapped if indeed they need that memory) Well people are asking for it ... doesn't that suggest they would use it? > > > IMHO offline mode is a good idea, especially when combined with a systray > > icon. It would also help with e.g. connections that are throttled or billed > > severely at certain times of day. > > There is a branch for "bandwidth-scheduling" in svn > (https://emu.freenetproject.org/svn/branches/bandwidth-scheduler) is > wavey still around and working on it? what's its status? AFAIK wavey disappeared. :| -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081231/4551ef2d/attachment.pgp>
