* 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)
- A low value will make flow analysis harder and might help with
sneaky QoS network policies
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.
> #3 tied: 33 votes : dynamic pages
>
> "I would like to see the ability to host dynamicly changing pages in freenet,
> I have tried to implement it myself and found it verry hard. Possibly
> integration with apache would be perfect."
>
> This may happen eventually, but probably post 1.0. Sandboxed plugins are
> probably the best approach, but even with a defined API and sandboxing, there
> are a lot of security issues innate in Freenet itself e.g. timing attacks on
> the datastore.
>
Agreed, way to complex to be implemented any time 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)
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20081231/6968cd18/attachment.pgp>
