[freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Matthew Toseland 
On Thursday 15 Mar 2012 20:24:10 Evan Daniel wrote:
> On Thu, Mar 15, 2012 at 10:22 AM, Matthew Toseland
>  wrote:
> > commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
> > Author: Matthew Toseland 
> > Date:   Thu Mar 15 14:18:10 2012 +
> >
> >Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on 
> > the high end of the peers limit. Reduce the multiplier, so it takes more 
> > bandwidth to have 40 peers; this should improve the average bandwidth per 
> > connection.
> >
> > This is actually from evanbd:
> >
> > [17:11:04]  evanbd: what was your new proposed formula for 
> > bandwidth/peers limit?
> > [17:11:19]  evanbd: we should try that out in 1406 if there aren't 
> > any other major changes, and in 1407 if there are
> > [17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in 
> > KiB/s.
> > [17:11:47]  ok
> > [17:11:54]  I'm proposing changing the 12 to 6 or so.
> > [17:12:07]  ahhh
> > [17:12:26]  meaning high bandwidth nodes have the same number of 
> > peers but middle ones have less => higher bandwidth per peer
> > [17:12:34]  Exactly.
> > [17:13:03]  okay, we should do that soon
> >
> > This should be in 1406 or 1407.
> 
> Oops, had that in my branch, looks like I forgot to do a pull request.
> Anyway, thanks!

This should be merged soon after 1406 IMHO. We want to have one network level 
change per build, and there are some minor things in 1406 (deadlock fixes and 
the location thingy).
> 
> Evan
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/554d/attachment.pgp>

[freenet-dev] New Snapshot: testing-build-1406-pre2

2012-03-15 Thread David ‘Bombe’ Roden 
Hey, everypony.

I just release testing-build-1406-pre2. If you like to live on the edge
you can use the update script in your freenet directory to update your
current version to the testing version:

update.[cmd|sh] testing

This snapshot has also been pushed to github and can be found in the
?testing? branch.


Greetings,

David
-- 
David ?Bombe? Roden 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/446e9166/attachment.pgp>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

2012-03-15 Thread Ximin Luo 
 
>>> plugins.Library.index.ProtoIndexComponentSerialiser$TreeMapTranslator.rev(ProtoIndexComponentSerialiser.java:324)
>>> -- 
>>> plugins.Library.index.ProtoIndexComponentSerialiser$TreeMapTranslator.rev(ProtoIndexComponentSerialiser.java:310)
>>> -- 
>>> plugins.Library.util.SkeletonBTreeMap$NodeTranslator.rev(SkeletonBTreeMap.java:1519)
>>> -- 
>>> plugins.Library.util.SkeletonBTreeMap$TreeTranslator.rev(SkeletonBTreeMap.java:1582)
>>> -- 
>>> plugins.Library.util.SkeletonBTreeMap$TreeTranslator.rev(SkeletonBTreeMap.java:1551)
>>> -- 
>>> plugins.Library.index.ProtoIndexSerialiser$IndexTranslator.rev(ProtoIndexSerialiser.java:209)
>>> -- 
>>> plugins.Library.index.ProtoIndexSerialiser$IndexTranslator.rev(ProtoIndexSerialiser.java:134)
>>> -- 
>>> plugins.Library.index.ProtoIndexSerialiser.pull(ProtoIndexSerialiser.java:121)
>>> -- plugins.Library.Library.getIndex(Library.java:677) --
>>> plugins.Library.Library.getIndex(Library.java:640) --
>>> plugins.Library.Library.getIndex(Library.java:616) --
>>> plugins.Library.search.Search.splitQuery(Search.java:245) --
>>> plugins.Library.search.Search.startSearch(Search.java:111) --
>>> plugins.Library.search.Search.splitQuery(Search.java:347) --
>>> plugins.Library.search.Search.startSearch(Search.java:111) --
>>> plugins.Library.search.Search.startSearch(Search.java:117) --
>>> plugins.Library.ui.MainPage.processPostRequest(MainPage.java:192) --
>>> plugins.Library.ui.MainPageToadlet.handleMethodPOST(MainPageToadlet.java:96)
>>> -- sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) --
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> -- 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> -- java.lang.reflect.Method.invoke(Method.java:597) --
>>> freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:564)
>>> -- 
>>> freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:1102)
>>> -- freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:233)
>>> -- freenet.support.io.NativeThread.run(NativeThread.java:130)
>>> java.lang.ClassCastException: java.lang.String cannot be cast to
>>> java.lang.Double -- java.lang.Double.compareTo(Double.java:32) --
>>> java.util.TreeMap.getEntry(TreeMap.java:328) --
>>> java.util.TreeMap.get(TreeMap.java:255) --
>>> plugins.Library.util.SkeletonTreeMap.putGhost(SkeletonTreeMap.java:95)
>>> -- 
>>> plugins.Library.util.SkeletonTreeMap$TreeMapTranslator.rev(SkeletonTreeMap.java:327)
>>> -- 
>>> plugins.Library.index.ProtoIndexComponentSerialiser$TreeMapTranslator.rev(ProtoIndexComponentSerialiser.java:324)
>>> -- 
>>> plugins.Library.index.ProtoIndexComponentSerialiser$TreeMapTranslator.rev(ProtoIndexComponentSerialiser.java:310)
>>> -- 
>>> plugins.Library.util.SkeletonBTreeMap$NodeTranslator.rev(SkeletonBTreeMap.java:1519)
>>> -- 
>>> plugins.Library.util.SkeletonBTreeMap$TreeTranslator.rev(SkeletonBTreeMap.java:1582)
>>> -- 
>>> plugins.Library.util.SkeletonBTreeMap$TreeTranslator.rev(SkeletonBTreeMap.java:1551)
>>> -- 
>>> plugins.Library.index.ProtoIndexSerialiser$IndexTranslator.rev(ProtoIndexSerialiser.java:209)
>>> -- 
>>> plugins.Library.index.ProtoIndexSerialiser$IndexTranslator.rev(ProtoIndexSerialiser.java:134)
>>> -- 
>>> plugins.Library.index.ProtoIndexSerialiser.pull(ProtoIndexSerialiser.java:121)
>>> -- plugins.Library.Library.getIndex(Library.java:677) --
>>> plugins.Library.Library.getIndex(Library.java:640) --
>>> plugins.Library.Library.getIndex(Library.java:616) --
>>> plugins.Library.search.Search.splitQuery(Search.java:245) --
>>> plugins.Library.search.Search.startSearch(Search.java:111) --
>>> plugins.Library.search.Search.splitQuery(Search.java:347) --
>>> plugins.Library.search.Search.startSearch(Search.java:111) --
>>> plugins.Library.search.Search.startSearch(Search.java:117) --
>>> plugins.Library.ui.MainPage.processPostRequest(MainPage.java:192) --
>>> plugins.Library.ui.MainPageToadlet.handleMethodPOST(MainPageToadlet.java:96)
>>> -- sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) --
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> -- 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> -- java.lang.reflect.Method.invoke(Method.java:597) --
>>> freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:564)
>>> -- 
>>> freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:1102)
>>> -- freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:233)
>>> -- freenet.support.io.NativeThread.run(NativeThread.java:130)
>>>
>>> What do you think?
>>>
>>> --
>>> I may disagree with what you have to say, but I shall defend, to the
>>> death, your right to say it. - Voltaire
>>> Those who would give up Liberty, to purchase temporary Safety, deserve
>>> neither Liberty nor Safety. - Ben Franklin
>>
>>
>> -- 
>> GPG: 4096R/5FBBDBCE
>> https://github.com/infinity0
>> https://bitbucket.org/infinity0
>> https://launchpad.net/~infinity0
>>
>>


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/a7bf75e4/attachment.pgp>

[freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Evan Daniel 
On Thu, Mar 15, 2012 at 6:08 PM, Matthew Toseland
 wrote:
> On Thursday 15 Mar 2012 20:24:10 Evan Daniel wrote:
>> On Thu, Mar 15, 2012 at 10:22 AM, Matthew Toseland
>>  wrote:
>> > commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
>> > Author: Matthew Toseland 
>> > Date: ? Thu Mar 15 14:18:10 2012 +
>> >
>> > ? ?Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on 
>> > the high end of the peers limit. Reduce the multiplier, so it takes more 
>> > bandwidth to have 40 peers; this should improve the average bandwidth per 
>> > connection.
>> >
>> > This is actually from evanbd:
>> >
>> > [17:11:04]  evanbd: what was your new proposed formula for 
>> > bandwidth/peers limit?
>> > [17:11:19]  evanbd: we should try that out in 1406 if there aren't 
>> > any other major changes, and in 1407 if there are
>> > [17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in 
>> > KiB/s.
>> > [17:11:47]  ok
>> > [17:11:54]  I'm proposing changing the 12 to 6 or so.
>> > [17:12:07]  ahhh
>> > [17:12:26]  meaning high bandwidth nodes have the same number of 
>> > peers but middle ones have less => higher bandwidth per peer
>> > [17:12:34]  Exactly.
>> > [17:13:03]  okay, we should do that soon
>> >
>> > This should be in 1406 or 1407.
>>
>> Oops, had that in my branch, looks like I forgot to do a pull request.
>> Anyway, thanks!
>
> This should be merged soon after 1406 IMHO. We want to have one network level 
> change per build, and there are some minor things in 1406 (deadlock fixes and 
> the location thingy).

I like that plan.

Evan

[freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Evan Daniel 
On Thu, Mar 15, 2012 at 10:22 AM, Matthew Toseland
 wrote:
> commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
> Author: Matthew Toseland 
> Date: ? Thu Mar 15 14:18:10 2012 +
>
> ? ?Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on the 
> high end of the peers limit. Reduce the multiplier, so it takes more 
> bandwidth to have 40 peers; this should improve the average bandwidth per 
> connection.
>
> This is actually from evanbd:
>
> [17:11:04]  evanbd: what was your new proposed formula for 
> bandwidth/peers limit?
> [17:11:19]  evanbd: we should try that out in 1406 if there aren't any 
> other major changes, and in 1407 if there are
> [17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in 
> KiB/s.
> [17:11:47]  ok
> [17:11:54]  I'm proposing changing the 12 to 6 or so.
> [17:12:07]  ahhh
> [17:12:26]  meaning high bandwidth nodes have the same number of peers 
> but middle ones have less => higher bandwidth per peer
> [17:12:34]  Exactly.
> [17:13:03]  okay, we should do that soon
>
> This should be in 1406 or 1407.
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Oops, had that in my branch, looks like I forgot to do a pull request.
Anyway, thanks!

Evan

Re: [freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Evan Daniel 
On Thu, Mar 15, 2012 at 6:08 PM, Matthew Toseland
 wrote:
> On Thursday 15 Mar 2012 20:24:10 Evan Daniel wrote:
>> On Thu, Mar 15, 2012 at 10:22 AM, Matthew Toseland
>>  wrote:
>> > commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
>> > Author: Matthew Toseland 
>> > Date:   Thu Mar 15 14:18:10 2012 +
>> >
>> >    Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on 
>> > the high end of the peers limit. Reduce the multiplier, so it takes more 
>> > bandwidth to have 40 peers; this should improve the average bandwidth per 
>> > connection.
>> >
>> > This is actually from evanbd:
>> >
>> > [17:11:04]  evanbd: what was your new proposed formula for 
>> > bandwidth/peers limit?
>> > [17:11:19]  evanbd: we should try that out in 1406 if there aren't 
>> > any other major changes, and in 1407 if there are
>> > [17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in 
>> > KiB/s.
>> > [17:11:47]  ok
>> > [17:11:54]  I'm proposing changing the 12 to 6 or so.
>> > [17:12:07]  ahhh
>> > [17:12:26]  meaning high bandwidth nodes have the same number of 
>> > peers but middle ones have less => higher bandwidth per peer
>> > [17:12:34]  Exactly.
>> > [17:13:03]  okay, we should do that soon
>> >
>> > This should be in 1406 or 1407.
>>
>> Oops, had that in my branch, looks like I forgot to do a pull request.
>> Anyway, thanks!
>
> This should be merged soon after 1406 IMHO. We want to have one network level 
> change per build, and there are some minor things in 1406 (deadlock fixes and 
> the location thingy).

I like that plan.

Evan
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Matthew Toseland 
On Thursday 15 Mar 2012 20:24:10 Evan Daniel wrote:
> On Thu, Mar 15, 2012 at 10:22 AM, Matthew Toseland
>  wrote:
> > commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
> > Author: Matthew Toseland 
> > Date:   Thu Mar 15 14:18:10 2012 +
> >
> >Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on 
> > the high end of the peers limit. Reduce the multiplier, so it takes more 
> > bandwidth to have 40 peers; this should improve the average bandwidth per 
> > connection.
> >
> > This is actually from evanbd:
> >
> > [17:11:04]  evanbd: what was your new proposed formula for 
> > bandwidth/peers limit?
> > [17:11:19]  evanbd: we should try that out in 1406 if there aren't 
> > any other major changes, and in 1407 if there are
> > [17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in 
> > KiB/s.
> > [17:11:47]  ok
> > [17:11:54]  I'm proposing changing the 12 to 6 or so.
> > [17:12:07]  ahhh
> > [17:12:26]  meaning high bandwidth nodes have the same number of 
> > peers but middle ones have less => higher bandwidth per peer
> > [17:12:34]  Exactly.
> > [17:13:03]  okay, we should do that soon
> >
> > This should be in 1406 or 1407.
> 
> Oops, had that in my branch, looks like I forgot to do a pull request.
> Anyway, thanks!

This should be merged soon after 1406 IMHO. We want to have one network level 
change per build, and there are some minor things in 1406 (deadlock fixes and 
the location thingy).
> 
> Evan


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Matthew Toseland 
commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
Author: Matthew Toseland 
Date:   Thu Mar 15 14:18:10 2012 +

Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on the 
high end of the peers limit. Reduce the multiplier, so it takes more bandwidth 
to have 40 peers; this should improve the average bandwidth per connection.

This is actually from evanbd:

[17:11:04]  evanbd: what was your new proposed formula for 
bandwidth/peers limit?
[17:11:19]  evanbd: we should try that out in 1406 if there aren't any 
other major changes, and in 1407 if there are
[17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in KiB/s.
[17:11:47]  ok
[17:11:54]  I'm proposing changing the 12 to 6 or so.
[17:12:07]  ahhh
[17:12:26]  meaning high bandwidth nodes have the same number of peers 
but middle ones have less => higher bandwidth per peer
[17:12:34]  Exactly.
[17:13:03]  okay, we should do that soon

This should be in 1406 or 1407.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/3b9eb69b/attachment.pgp>

Re: [freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

2012-03-15 Thread Ximin Luo 
(Top-posting because previous post is too long to reply to in-line.)

## refactoring

Refactoring the code helps to make it more understandable for other coders. One
of the reasons why I don't work more on freenet myself is because it's
extremely difficult to make any changes that are more than a simple bug fix.

When I was writing code for the config subsystem to separate out different
files into different directories, this was very frustrating and took up much
more time than I expected.

NB: I'm not implying you should be doing all the work toad, please don't think
this. And please don't think that my opinions are automatically invalid / less
worthy just because I haven't committed code for ages. I just want to express
my view of What I Would Do If I Were God.

People can do what they want but it doesn't mean it's a good idea. Granted, I
consider "code quality" independently of any issues such as funding, but
focusing too much on the latter leads to bad software. If there's pressure like
this, ignore it, find something else in the meantime until it goes away.

## freenet Events API

freenet does not provide a great API for running callbacks and scheduled tasks.
Converting everything to use java.util.concurrent and/or
com.google.common.util.concurrent would help this a lot. Of course, Library can
and currently does implement this itself, but it's fairly sloppy, and other
plugins would benefit if such a framework were provided.

Some common tasks that plugins would like to do, which really should be
provided by the underlying application:
- run tasks in the background
- run tasks according to a particular schedule
- cancel running tasks
- handle dependencies between tasks, so that e.g. if A depends on B and I
cancel B, A is automatically cancelled.
- group tasks into related categories so one group doesn't affect the other.
(e.g. tasks for the group "Library/b-tree-write/index-" won't starve the
resources of group "WoT/background-trust-calculation")

## Library algorithm

You keep talking about specific things like "only fetching a single block in
the common case". Nobody else knows what this means, even I don't (off the top
of my head) because I haven't looked at the code in several years.

Having a proper specification that separates different concerns out into layers
(e.g. logical structure; on-freenet structure; data format; network
performance) helps greatly to make the algorithm understandable to other
people, and yourself if you don't work on it for ages.

If, instead of saying "only fetch a single block" you say "the on-freenet
structure format has persistence issues, and here's a potential solution", it's
easier for other people to understand what you mean.

## config management

Code for read/writing the config in embedded inside the classes they control,
which clutters up the code and makes it confusing. Config code should be
separated from the actual application. It would also be nice if this was
exposed to plugins.

Being a daemon is why the current config system is NOT SUFFICIENT. I need to be
able to lock certain config settings, such as where to keep the datastore /
run-time files themselves, to conform to the FHS. It's best that such settings
are kept in a separate read-only file. The current system only reads one file,
freenet.ini.

Updating its own binaries is not a problem if freenet knows where the binaries
are. The current installer puts them in a rigid place, however this is
incompatible with FHS.

X

On 15/03/12 13:03, Matthew Toseland wrote:
> On Wednesday 14 Mar 2012 11:49:33 Ximin Luo wrote:
>> Library has some architectural problems. I don't think it's a great use of 
>> time
>> to try to improve the existing code directly.
>>
>> - We didn't create a proper specification for how the data structure should
>> work over freenet
>> - I made a mistake in trying to shoe-horn a stub remote data structure into 
>> the
>> Java collections framework.
>> - To support loading from remote, I wrote my own event handling framework,
>> which was not a very clean design as I wasn't familiar with
>> java.util.concurrent at the time.
>> - I did write an asynchronous merge algorithm (SkelBTreeMap.update) which
>> currently does the majority of the write work, but it's quite complex and
>> doesn't integrate well with the rest of the code. Toad also made some
>> adjustments on top of it for performance, which makes understanding it even
>> more complex as it distracts from the "pure" form of the algorithm.
>>
>> What is needed to get Library working well is to:
>>
>> 1. specify the data structure, and associated algorithms, properly. I have
>> notes, I can help with this
>> 2. use an event handling framework for Java (something similar to Twisted for
>> python, but also has the ability to use threads if necessary)
>> 3. use this to implement the algorithm in a concise way
> 
> Some functional stuff for Library (related to on-network format), that may or 
> may not fit in depending on how much is bein

[freenet-dev] Is anyone maintaining lib-pyFreenet? was Fwd: [lib-pyFreenet-staging] added dummy handling of the new FCP Messages CompatibilityMode, Expected... (#1)

2012-03-15 Thread Matthew Toseland 
I'm not competent even to review merge requests for this really. Anyone deal?
-- next part --
An embedded message was scrubbed...
From: Arne Babenhauserheide 

Subject: [lib-pyFreenet-staging] added dummy handling of the new FCP Messages 
CompatibilityMode, Expected... (#1)
Date: Sat, 25 Feb 2012 05:23:42 -0800
Size: 2461
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/aa2419a6/attachment.mht>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/aa2419a6/attachment.pgp>

Re: [freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Evan Daniel 
On Thu, Mar 15, 2012 at 10:22 AM, Matthew Toseland
 wrote:
> commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
> Author: Matthew Toseland 
> Date:   Thu Mar 15 14:18:10 2012 +
>
>    Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on the 
> high end of the peers limit. Reduce the multiplier, so it takes more 
> bandwidth to have 40 peers; this should improve the average bandwidth per 
> connection.
>
> This is actually from evanbd:
>
> [17:11:04]  evanbd: what was your new proposed formula for 
> bandwidth/peers limit?
> [17:11:19]  evanbd: we should try that out in 1406 if there aren't any 
> other major changes, and in 1407 if there are
> [17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in 
> KiB/s.
> [17:11:47]  ok
> [17:11:54]  I'm proposing changing the 12 to 6 or so.
> [17:12:07]  ahhh
> [17:12:26]  meaning high bandwidth nodes have the same number of peers 
> but middle ones have less => higher bandwidth per peer
> [17:12:34]  Exactly.
> [17:13:03]  okay, we should do that soon
>
> This should be in 1406 or 1407.
>
> ___
> Devl mailing list
> Devl@freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Oops, had that in my branch, looks like I forgot to do a pull request.
Anyway, thanks!

Evan
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] New Snapshot: testing-build-1406-pre2

2012-03-15 Thread David ‘Bombe’ Roden 
Hey, everypony.

I just release testing-build-1406-pre2. If you like to live on the edge
you can use the update script in your freenet directory to update your
current version to the testing version:

update.[cmd|sh] testing

This snapshot has also been pushed to github and can be found in the
“testing” branch.


Greetings,

David
-- 
David ‘Bombe’ Roden 


signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] webui and accessibility

2012-03-15 Thread Matthew Toseland 
On Tuesday 13 Mar 2012 02:54:47 Steve Dougherty wrote:
> I very much like this idea! Presenting a single page with choices,
> especially when the final button is "Finish and connect now" is a
> superb way to speed up the first run setup. The current use of
> multiple pages without even a progress bar puts more pressure on each
> decision and feels very slow.
> 
> Hopefully we could add arrows next to the options which can be clicked
> to expand with additional explanation and information instead of
> presenting a wall of text.
> 
> Does someone else want to implement this? I'd love to, but I won't
> have time for almost two months.

I'd be willing to implement it if nobody else does (I'm sure Ian would be 
delighted with it!). We need to discuss the details first but it's looking 
promising.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/4a21c3d1/attachment.pgp>

[freenet-dev] Fewer pages was Re: webui and accessibility

2012-03-15 Thread Matthew Toseland 
On Sunday 11 Mar 2012 12:53:11 Arne Babenhauserheide wrote:
> Am Freitag, 9. M?rz 2012, 21:52:22 schrieb Steve Dougherty:
> > Should we get rid of more of the steps in the first-run setup? 
> 
> I think yes - if people choose the default installation, they should not be 
> forced to take additional decisions.

The main difficulty is, one complex page is not better than four simple pages.
> 
> Maybe it would even be possible to just show a pane ?Basic Config? which 
> shows 
> preselected configuration values, each with an edit-button (?change?).
> 
> (I use [button] for buttons with the text ?button?)
> 
> ### Basic Config ###

Language should normally be set by the installer. We already automatically 
enable UPnP, turn off JSTUN, and enable auto-updating on LOW security. I think 
we ask about them on HIGH? We don't need to ask about auto-updating IMHO, and 
JSTUN is too much of a risk for the more paranoid folk; UPnP is only dangerous 
on student LANs and even there there isn't that much they can do to you.

We still need to ask for low security/high security as the first page, with 
custom = expert mode. Maybe we should rename "Custom security" to "Expert mode" 
?

Browser warnings should go away most of the time.
> 
> Please check the default configuration. Change values which don?t fit:
> 
> * Encrypted Datastore Size: 2 GiB [change]

This is sensible. We can produce a sensible default, we can combine it.

> * Assigned Bandwidth: 10 KiB/s (26 GiB per month) [change]

Most connections are asymmetric but Freenet's usage is fairly asymmetric. 
Whether ISPs charge for / cap total monthly transfer or just download varies. 
Showing just the output limit probably makes sense here, there's no sense 
limiting download since it's almost entirely driven by usage... unless you have 
a monthly cap. Hmmm ... We are trying to avoid having to show 
cover-your-backside explanation messages here as they bloat everything out to 
multiple pages ... Maybe we can get away with "26GB per month plus your 
downloads" or something though.

One day we will have the ability to set a monthly limit AS WELL as the 
bandwidth limit here. We can deal with that on clicking Change though...

On LOW security, we don't ask for a password. On HIGH, we ask. Either way we 
encrypt using master.keys. We could maybe include that here too.

> * ?
> 
> [Finish and connect now]
> 
> (4 values, one for each pane of the current wizard)
> 
> > I2P works very nicely with
> > something that would work without Javascript, but works much better
> > with: it shows for a given speed setting how much it will likely use per
> > month. That a way better way to deal with monthly bandwidth limits than
> > asking directly.
> 
> I would like that.

I agree that is important. It doesn't need Javascript though.
> 
> Best wishes,
> Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/418fe494/attachment.pgp>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

2012-03-15 Thread Matthew Toseland 
veMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > -- 
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > -- java.lang.reflect.Method.invoke(Method.java:597) --
> > freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:564)
> > -- 
> > freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:1102)
> > -- freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:233)
> > -- freenet.support.io.NativeThread.run(NativeThread.java:130)
> > 
> > What do you think?
> > 
> > --
> > I may disagree with what you have to say, but I shall defend, to the
> > death, your right to say it. - Voltaire
> > Those who would give up Liberty, to purchase temporary Safety, deserve
> > neither Liberty nor Safety. - Ben Franklin
> 
> 
> -- 
> GPG: 4096R/5FBBDBCE
> https://github.com/infinity0
> https://bitbucket.org/infinity0
> https://launchpad.net/~infinity0
> 
> 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/c0c35f1c/attachment.pgp>

[freenet-dev] fproxy-ng first draft and a short roadmap

2012-03-15 Thread Matthew Toseland 
On Wednesday 14 Mar 2012 11:44:12 Nicolas Hernandez wrote:
> http://dl.dropbox.com/u/67035152/fproxy-ng.png

Looks interesting! Is XHTML11Renderer something you are going to have to write 
or something that GWT provides? Either way, there will be basically a common 
base of templates and code, we don't have to pre-render templates at compile 
time or anything?

One advantage of using GWT is we're already using it for web-pushing; maybe 
that'll get debugged now, or maybe you'll replace it. Of course if you don't 
need client-pulling-events-from-node functionality that's fine too, somebody 
else can debug it some day!

The current web-pushing code is located here:

src/freenet/clients/http/updateableelements/
src/freenet/clients/http/ajaxpush/
generator/js/

> It should be ok
> 
> - Nicolas Hernandez
> a-n - aleph-networks
> *associ?*
> http://www.aleph-networks.com
> 
> 
> 
> 
> On Wed, Mar 14, 2012 at 12:01 PM, Ian Clarke  
> wrote:
> 
> > On Sun, Mar 11, 2012 at 5:07 PM, Nicolas Hernandez <
> > nicolas.hernandez at aleph-networks.com> wrote:
> >
> >> Here is the first draft of http://dl.free.fr/h8FSuBGNG 
> >> <http://dl.free.fr/h8FSuBGNG>
> >>
> >
> > Nicolas, I can't seem to download this, I click on "T?l?charger ce
> > fichier" but nothing happens :-/
> >
> > You might want to consider using http://dropbox.com/.
> >
> > Ian.
> >
> >
> > --
> > Ian Clarke
> > Founder, The Freenet Project
> > Email: ian at freenetproject.org
> >
> > ___
> > Devl mailing list
> > Devl at freenetproject.org
> > http://freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/7b484bdb/attachment.pgp>

[freenet-dev] A general question about heavy UI

2012-03-15 Thread Matthew Toseland 
On Wednesday 14 Mar 2012 10:53:02 Nicolas Hernandez wrote:
> Hello,
> 
> One of my expert (francis) ask me if it is a good idea to developp a
> frontend like Azureus wich could embed a freenet node ?
> Have you some reasons to say that this is a bad idea as personnal time
> invertissment ? The Freenet dev community is ok to receive this sort of
> contribution ?

It's essential that Freenet itself can run as a daemon, i.e. without a GUI. It 
could minimise to system tray or something though. Usually front ends talk to 
freenet via FCP. This is flexible.

Uptime: Freenet needs high uptime if at all possible. So it should be able to 
run in the background, possibly minimising to system tray, but anything that 
encourages on-demand usage is going to lead to poor performance; freenet should 
start on login by default, although of course that can be configurable.

A front end is interesting in a number of ways though. Most of them relate to 
fproxy:
- Avoid loads of browser hacks, most of them related to security.
- Control audio/video playback in detail, avoid the need to filter audio/video.
- Faster, simpler web-pushing style response (e.g. have a single progress bar 
for all images on the page which takes into account sub-blocks).

The ones that don't really relate to fproxy:
- Better GUI for choosing where to upload files from or save them to.
- Transparently avoid security issues with this on a multi-user system (as the 
UI is running as the logged in user).

Some stuff related to this is here:
https://bugs.freenetproject.org/view.php?id=2830

Personally I don't think that a web UI is a necessarily bad UI; how many people 
use webmail for their email today? Way more than use dedicated email clients. 
Traditionally p2p software has had windowed UIs, but that doesn't mean they are 
easy to use. Freenet's ease of use (and even aesthetic) problems come from 
other areas e.g. determining what the user does and does not need to be asked 
about.

A further complication is that if you write a front-end and people like it they 
may want it on their One True Platform ... :)

IMHO the most important thing is sorting out the web interface. But I wouldn't 
be opposed to you developing a windowed UI.

(Also note somebody did develop an Azureus plugin; at the time the performance 
of downloads was around 1KB/sec, this was the main difficulty! It's a bit 
better than that today for popular/recent files :) )
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120315/84ca302d/attachment.pgp>

[freenet-dev] Tweaking the peer limit scaling constant

2012-03-15 Thread Matthew Toseland 
commit cb21f7d4bc5e1940b6acdb49004b912f8fb705e5
Author: Matthew Toseland 
Date:   Thu Mar 15 14:18:10 2012 +

Tweak peers limit by bandwidth SCALING_CONSTANT: Lots of peers are on the 
high end of the peers limit. Reduce the multiplier, so it takes more bandwidth 
to have 40 peers; this should improve the average bandwidth per connection.

This is actually from evanbd:

[17:11:04]  evanbd: what was your new proposed formula for 
bandwidth/peers limit?
[17:11:19]  evanbd: we should try that out in 1406 if there aren't any 
other major changes, and in 1407 if there are
[17:11:43]  Currently, it's peers = sqrt(12*limit), with limit in KiB/s.
[17:11:47]  ok
[17:11:54]  I'm proposing changing the 12 to 6 or so.
[17:12:07]  ahhh
[17:12:26]  meaning high bandwidth nodes have the same number of peers 
but middle ones have less => higher bandwidth per peer
[17:12:34]  Exactly.
[17:13:03]  okay, we should do that soon

This should be in 1406 or 1407.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Is anyone maintaining lib-pyFreenet? was Fwd: [lib-pyFreenet-staging] added dummy handling of the new FCP Messages CompatibilityMode, Expected... (#1)

2012-03-15 Thread Matthew Toseland 
I'm not competent even to review merge requests for this really. Anyone deal?
--- Begin Message ---
...Hashes, ExpectedMIME and ExpectedDataLength.

Mime actually gets used to set the mimetype for the job. The others are simply 
information that the transfer is still pending.

You can merge this Pull Request by running:

  git pull https://github.com/ArneBab/lib-pyFreenet-staging new-fcp

Or you can view, comment on it, or merge it online at:

  https://github.com/freenet/lib-pyFreenet-staging/pull/1

-- Commit Summary --

* added dummy handling of the new FCP Messages CompatibilityMode, 
ExpectedHashes, ExpectedMIME and ExpectedDataLength.

-- File Changes --

M fcp/node.py (37)

-- Patch Links --

  https://github.com/freenet/lib-pyFreenet-staging/pull/1.patch
  https://github.com/freenet/lib-pyFreenet-staging/pull/1.diff

--- 
Reply to this email directly or view it on GitHub:
https://github.com/freenet/lib-pyFreenet-staging/pull/1

--- End Message ---


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] webui and accessibility

2012-03-15 Thread Matthew Toseland 
On Tuesday 13 Mar 2012 02:54:47 Steve Dougherty wrote:
> I very much like this idea! Presenting a single page with choices,
> especially when the final button is "Finish and connect now" is a
> superb way to speed up the first run setup. The current use of
> multiple pages without even a progress bar puts more pressure on each
> decision and feels very slow.
> 
> Hopefully we could add arrows next to the options which can be clicked
> to expand with additional explanation and information instead of
> presenting a wall of text.
> 
> Does someone else want to implement this? I'd love to, but I won't
> have time for almost two months.

I'd be willing to implement it if nobody else does (I'm sure Ian would be 
delighted with it!). We need to discuss the details first but it's looking 
promising.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Fewer pages was Re: webui and accessibility

2012-03-15 Thread Matthew Toseland 
On Sunday 11 Mar 2012 12:53:11 Arne Babenhauserheide wrote:
> Am Freitag, 9. März 2012, 21:52:22 schrieb Steve Dougherty:
> > Should we get rid of more of the steps in the first-run setup? 
> 
> I think yes - if people choose the default installation, they should not be 
> forced to take additional decisions.

The main difficulty is, one complex page is not better than four simple pages.
> 
> Maybe it would even be possible to just show a pane “Basic Config” which 
> shows 
> preselected configuration values, each with an edit-button (“change”).
> 
> (I use [button] for buttons with the text “button”)
> 
> ### Basic Config ###

Language should normally be set by the installer. We already automatically 
enable UPnP, turn off JSTUN, and enable auto-updating on LOW security. I think 
we ask about them on HIGH? We don't need to ask about auto-updating IMHO, and 
JSTUN is too much of a risk for the more paranoid folk; UPnP is only dangerous 
on student LANs and even there there isn't that much they can do to you.

We still need to ask for low security/high security as the first page, with 
custom = expert mode. Maybe we should rename "Custom security" to "Expert mode" 
?

Browser warnings should go away most of the time.
> 
> Please check the default configuration. Change values which don’t fit:
> 
> * Encrypted Datastore Size: 2 GiB [change]

This is sensible. We can produce a sensible default, we can combine it.

> * Assigned Bandwidth: 10 KiB/s (26 GiB per month) [change]

Most connections are asymmetric but Freenet's usage is fairly asymmetric. 
Whether ISPs charge for / cap total monthly transfer or just download varies. 
Showing just the output limit probably makes sense here, there's no sense 
limiting download since it's almost entirely driven by usage... unless you have 
a monthly cap. Hmmm ... We are trying to avoid having to show 
cover-your-backside explanation messages here as they bloat everything out to 
multiple pages ... Maybe we can get away with "26GB per month plus your 
downloads" or something though.

One day we will have the ability to set a monthly limit AS WELL as the 
bandwidth limit here. We can deal with that on clicking Change though...

On LOW security, we don't ask for a password. On HIGH, we ask. Either way we 
encrypt using master.keys. We could maybe include that here too.

> * …
> 
> [Finish and connect now]
> 
> (4 values, one for each pane of the current wizard)
> 
> > I2P works very nicely with
> > something that would work without Javascript, but works much better
> > with: it shows for a given speed setting how much it will likely use per
> > month. That a way better way to deal with monthly bandwidth limits than
> > asking directly.
> 
> I would like that.

I agree that is important. It doesn't need Javascript though.
> 
> Best wishes,
> Arne


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

2012-03-15 Thread Matthew Toseland 
On Wednesday 14 Mar 2012 11:49:33 Ximin Luo wrote:
> Library has some architectural problems. I don't think it's a great use of 
> time
> to try to improve the existing code directly.
> 
> - We didn't create a proper specification for how the data structure should
> work over freenet
> - I made a mistake in trying to shoe-horn a stub remote data structure into 
> the
> Java collections framework.
> - To support loading from remote, I wrote my own event handling framework,
> which was not a very clean design as I wasn't familiar with
> java.util.concurrent at the time.
> - I did write an asynchronous merge algorithm (SkelBTreeMap.update) which
> currently does the majority of the write work, but it's quite complex and
> doesn't integrate well with the rest of the code. Toad also made some
> adjustments on top of it for performance, which makes understanding it even
> more complex as it distracts from the "pure" form of the algorithm.
> 
> What is needed to get Library working well is to:
> 
> 1. specify the data structure, and associated algorithms, properly. I have
> notes, I can help with this
> 2. use an event handling framework for Java (something similar to Twisted for
> python, but also has the ability to use threads if necessary)
> 3. use this to implement the algorithm in a concise way

Some functional stuff for Library (related to on-network format), that may or 
may not fit in depending on how much is being thrown out and rewritten:
- B+tree (no data in the nodes so reduced depth), not B-tree
- Do we need any on-network changes to limit memory usage? Maybe consider how 
to deal with term positions...
- Some optimisations were proposed that might allow for only fetching a single 
block in the common case (we'd fetch 2 others for redundancy as well); this 
would probably require a binary format and might run into metadata size issues?
See the bug tracker anyway.

https://bugs.freenetproject.org/view.php?id=4066
And categories: 
library
b-tree-index

Also, there is another search plugin, it doesn't scale but has a very compact 
format and is very fast. Worth having a look and/or reaching out to its 
anonymous author? I dunno what the current status is. I never got around to 
making it an official plugin but the rumour was that it worked well. It's a 
shame not to bring in an anonymous contributor who goes to the trouble of 
writing a working plugin...
> 
> freenet itself should use something like this as well - atm it uses its own
> custom solution which is a bit messy and not well-separated from the rest of
> the code. 

For what exactly? I'm not sure I follow?

One thing we MUST MUST MUST be able to do is *WRITE* the config file. Obviously 
this is optional, and on some unixy setups with a competent admin we can run 
without the ability to write the config file; but for 99.9% of users the 
ability to configure Freenet in a GUI way is useful, and from time to time it 
is helpful to be able to update config settings from e.g. a useralert.

> It also uses many of its own crypto and concurrent utilities, which
> bloats the code for no reason.

True. I have no problem with replacing them with the standard stuff provided 
the impact on performance on the common case of no hardware acceleration is 
positive or negligible. (The API is a bit messy). Also, are we sure the JVM 
export keylength BS is finished, over and gone?

One major complication is quite a lot of Freenet uses 256/256 AES which is sort 
of nonstandard, and probably not going to be hardware accelerated. Replacing it 
would probably involve changing some link-level formats e.g. so we could use 
CBC. Likewise PCFB is fairly widely used, which is also somewhat nonstandard, 
although with 256/256 it is identical to CFB, which is more common.

Let me know what you need, but I'm not going to do all the work for you. We 
have plenty of back compatibility related stuff in place - autonegotiation of 
connection type, version numbers on keys etc.
> 
> In other words, both Library and freenet (probably freenet first) needs some
> major refactoring work, before major "features" can progress.

No, I disagree. Refactoring can happen at any time, if a new major feature 
depends on it then it should be expedited. However I'm happy to accept your 
view re Library; re Freenet, I'm happy for other people to do refactorings they 
see as important, but I don't have time (or funding) for anything large myself.
> 
> Most of this requires that freenet-ext be available as separate modules, which
> needs an overhaul of the update-over-freenet system as that currently assumse
> freenet-ext comes in a single JAR.

Yes, this is important. The tricky part here is it would affect *everything*: 
The installer, the manual update scripts, the updater ... Let me know what you 
need.
> 
> Oh, and another thing, the config framework is horrible and we really should
> use an existing external solution. 

Possibly. It works; what are the main problems as you see it? I'm certainly

Re: [freenet-dev] fproxy-ng first draft and a short roadmap

2012-03-15 Thread Matthew Toseland 
On Wednesday 14 Mar 2012 11:44:12 Nicolas Hernandez wrote:
> http://dl.dropbox.com/u/67035152/fproxy-ng.png

Looks interesting! Is XHTML11Renderer something you are going to have to write 
or something that GWT provides? Either way, there will be basically a common 
base of templates and code, we don't have to pre-render templates at compile 
time or anything?

One advantage of using GWT is we're already using it for web-pushing; maybe 
that'll get debugged now, or maybe you'll replace it. Of course if you don't 
need client-pulling-events-from-node functionality that's fine too, somebody 
else can debug it some day!

The current web-pushing code is located here:

src/freenet/clients/http/updateableelements/
src/freenet/clients/http/ajaxpush/
generator/js/

> It should be ok
> 
> - Nicolas Hernandez
> a-n - aleph-networks
> *associé*
> http://www.aleph-networks.com
> 
> 
> 
> 
> On Wed, Mar 14, 2012 at 12:01 PM, Ian Clarke  wrote:
> 
> > On Sun, Mar 11, 2012 at 5:07 PM, Nicolas Hernandez <
> > nicolas.hernan...@aleph-networks.com> wrote:
> >
> >> Here is the first draft of http://dl.free.fr/h8FSuBGNG 
> >> 
> >>
> >
> > Nicolas, I can't seem to download this, I click on "Télécharger ce
> > fichier" but nothing happens :-/
> >
> > You might want to consider using http://dropbox.com/.
> >
> > Ian.
> >
> >
> > --
> > Ian Clarke
> > Founder, The Freenet Project
> > Email: i...@freenetproject.org
> >
> > ___
> > Devl mailing list
> > Devl@freenetproject.org
> > http://freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> 


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] A general question about heavy UI

2012-03-15 Thread Matthew Toseland 
On Wednesday 14 Mar 2012 10:53:02 Nicolas Hernandez wrote:
> Hello,
> 
> One of my expert (francis) ask me if it is a good idea to developp a
> frontend like Azureus wich could embed a freenet node ?
> Have you some reasons to say that this is a bad idea as personnal time
> invertissment ? The Freenet dev community is ok to receive this sort of
> contribution ?

It's essential that Freenet itself can run as a daemon, i.e. without a GUI. It 
could minimise to system tray or something though. Usually front ends talk to 
freenet via FCP. This is flexible.

Uptime: Freenet needs high uptime if at all possible. So it should be able to 
run in the background, possibly minimising to system tray, but anything that 
encourages on-demand usage is going to lead to poor performance; freenet should 
start on login by default, although of course that can be configurable.

A front end is interesting in a number of ways though. Most of them relate to 
fproxy:
- Avoid loads of browser hacks, most of them related to security.
- Control audio/video playback in detail, avoid the need to filter audio/video.
- Faster, simpler web-pushing style response (e.g. have a single progress bar 
for all images on the page which takes into account sub-blocks).

The ones that don't really relate to fproxy:
- Better GUI for choosing where to upload files from or save them to.
- Transparently avoid security issues with this on a multi-user system (as the 
UI is running as the logged in user).

Some stuff related to this is here:
https://bugs.freenetproject.org/view.php?id=2830

Personally I don't think that a web UI is a necessarily bad UI; how many people 
use webmail for their email today? Way more than use dedicated email clients. 
Traditionally p2p software has had windowed UIs, but that doesn't mean they are 
easy to use. Freenet's ease of use (and even aesthetic) problems come from 
other areas e.g. determining what the user does and does not need to be asked 
about.

A further complication is that if you write a front-end and people like it they 
may want it on their One True Platform ... :)

IMHO the most important thing is sorting out the web interface. But I wouldn't 
be opposed to you developing a windowed UI.

(Also note somebody did develop an Azureus plugin; at the time the performance 
of downloads was around 1KB/sec, this was the main difficulty! It's a bit 
better than that today for popular/recent files :) )


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl