of course welcome.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/1b372395/attachment.pgp>
whether transfers succeed or fail?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/874707de/attachment.pgp>
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/98efd425/attachment.pgp>
il to send a packet, we can decode it and split it up (with some sort of
flag indicating that decoding this message is conditional on not having
received the packet, to prevent race conditions).
>
> --
> Robert Hailey
>
> >
> > The proposed streams changes can be implemented without the New
> > Transport
> > Layer, but should be kept when it comes in.
> >>
> >> Cheers,
> >> Michael
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/938d19e5/attachment.pgp>
I think our policy on which sites we link to should be to judge them
solely on the basis of their utility to the end user. Any other
metric implies that we are exercising some kind of editorial
judgement, and that is a slippery slope.
So if this is useful, and well designed, we should link to it
On Wednesday 19 March 2008 21:32, Matthew Toseland wrote:
> Backoff does not effectively route around nodes which frequently produce
> transfer failures, because in almost all cases we will have more DNFs (and
> RNFs etc) than we do transfer failures.
>
> How can we deal with this? A separate ba
hanges can be implemented without the New Transport
Layer, but should be kept when it comes in.
>
> Cheers,
> Michael
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/f5da2e4e/attachment.pgp>
On Mar 19, 2008, at 1:56 PM, Matthew Toseland wrote:
> Should we include the AFKIndex? It is a good thing to have as many
> indexes as
> possible, and our policy is and has always been to link to indexes
> purely
> according to their value for finding content.
>
> However, the AFK index is an
irc.mozilla.org ...
Noone was able to answer me on #firefox but if you want to retry be my
guest. IRC and especially a public support channel aren't exactly a good way
of getting accurate informations about such a precise usecase.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/7197558c/attachment.pgp>
about
data-persistence related matters on freenet.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/0143848c/attachment.pgp>
Backoff does not effectively route around nodes which frequently produce
transfer failures, because in almost all cases we will have more DNFs (and
RNFs etc) than we do transfer failures.
How can we deal with this? A separate backoff tracker for transfer failures,
which only cares about whether
I think our policy on which sites we link to should be to judge them
solely on the basis of their utility to the end user. Any other
metric implies that we are exercising some kind of editorial
judgement, and that is a slippery slope.
So if this is useful, and well designed, we should link to it
On Mar 19 2008, Matthew Toseland wrote:
> Actually, I'm not sure we're finished here. What we really want to do, to
> minimise the chance of a timeout, is to alternate between the active
> transfers. With the code you implemented, if a block is in store, all of
> its packet transmits will be que
On Mar 19, 2008, at 9:51 AM, Matthew Toseland wrote:
> On Wednesday 19 March 2008 13:32, Michael Rogers wrote:
>> On Mar 19 2008, Matthew Toseland wrote:
>>> Actually, I'm not sure we're finished here. What we really want to
>>> do, to
>>> minimise the chance of a timeout, is to alternate betwe
On Mar 19, 2008, at 1:56 PM, Matthew Toseland wrote:
> Should we include the AFKIndex? It is a good thing to have as many
> indexes as
> possible, and our policy is and has always been to link to indexes
> purely
> according to their value for finding content.
>
> However, the AFK index is an
robert
nextgens
toad
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/e430f25f/attachment.pgp>
o do, to
minimise the chance of a timeout, is to alternate between the active
transfers. With the code you implemented, if a block is in store, all of its
packet transmits will be queued at the same time and therefore all other
transfers to the same peer will wait until they have all been sent, which
given bandwidth limiting could be a long time.
Suggestions?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/2b9cb446/attachment.pgp>
Should we include the AFKIndex? It is a good thing to have as many indexes as
possible, and our policy is and has always been to link to indexes purely
according to their value for finding content.
However, the AFK index is an auto-generated index *with activelinks*. Sites
are apparently automa
x :/
>
> Dealing with extensions mangling the HTML code is still an ongoing
> task... and I'm effraid there's no solution to deal with them short of
> trying to auto-generate the extension blacklisting file or starting FF
> in safe-mode.
Have you tried asking the firefox people? On irc.mozilla.org ...
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/f1a68fb9/attachment.pgp>
e want people to use the bookmark feature of fproxy?
So?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/1013b5e4/attachment.pgp>
On Wednesday 19 March 2008 18:02, Robert Hailey wrote:
>
> On Mar 19, 2008, at 9:51 AM, Matthew Toseland wrote:
>
> > On Wednesday 19 March 2008 13:32, Michael Rogers wrote:
> >> On Mar 19 2008, Matthew Toseland wrote:
> >>> Actually, I'm not sure we're finished here. What we really want to
> >
On Mar 19, 2008, at 9:51 AM, Matthew Toseland wrote:
> On Wednesday 19 March 2008 13:32, Michael Rogers wrote:
>> On Mar 19 2008, Matthew Toseland wrote:
>>> Actually, I'm not sure we're finished here. What we really want to
>>> do, to
>>> minimise the chance of a timeout, is to alternate betwe
On Wednesday 19 March 2008 13:32, Michael Rogers wrote:
> On Mar 19 2008, Matthew Toseland wrote:
> > Actually, I'm not sure we're finished here. What we really want to do, to
> > minimise the chance of a timeout, is to alternate between the active
> > transfers. With the code you implemented, if
* Matthew Toseland <[EMAIL PROTECTED]> [2008-03-19 11:56:29]:
> On Wednesday 19 March 2008 01:06, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-03-18 18:10:54]:
> >
> > > On Sunday 16 March 2008 10:29, [EMAIL PROTECTED] wrote:
> > > > Author: nextgens
> > > > Date: 200
* Matthew Toseland <[EMAIL PROTECTED]> [2008-03-19 11:55:30]:
> On Wednesday 19 March 2008 00:56, Florent Daignière wrote:
> > * Matthew Toseland <[EMAIL PROTECTED]> [2008-03-18 18:12:39]:
> >
> > > On Sunday 16 March 2008 12:14, [EMAIL PROTECTED] wrote:
> > > > Author: nextgens
> > > > Date: 200
On Mar 19 2008, Matthew Toseland wrote:
> Actually, I'm not sure we're finished here. What we really want to do, to
> minimise the chance of a timeout, is to alternate between the active
> transfers. With the code you implemented, if a block is in store, all of
> its packet transmits will be que
References=20080319015601.GH3506 at freenetproject.org
In-Reply-To=20080319015601.GH3506 at freenetproject.org
[Sorry if I broke a mailing-list reference chain, I wasn't subscribed,
so can't just reply and keep the References: fields, Thunderbird won't
take Lurker's extended mailto: tags and han
Freenet 0.7 build 1124 is now available. Please upgrade, it will be mandatory
on Friday. Changes include:
- Send queued blocks in the order they were queued, rather than in "random"
notify order. This should reduce the number of failing block transfers.
- Fix a few NullPointerException's, includi
On Monday 17 March 2008 15:30, Robert Hailey wrote:
>
> On Mar 15, 2008, at 1:03 PM, Matthew Toseland wrote:
>
> > Not convinced by _abandonedTickets:
> >
> > 1 new ticket
> > 2 new ticket
> > 3 new ticket
> > 4 new ticket
> > 2 times out
> > 3 times out
> > space to send (1)
> > 1-2 = -1 so we d
On Wednesday 19 March 2008 01:06, Florent Daignière wrote:
> * Matthew Toseland <[EMAIL PROTECTED]> [2008-03-18 18:10:54]:
>
> > On Sunday 16 March 2008 10:29, [EMAIL PROTECTED] wrote:
> > > Author: nextgens
> > > Date: 2008-03-16 10:29:28 + (Sun, 16 Mar 2008)
> > > New Revision: 18550
> > >
On Wednesday 19 March 2008 00:56, Florent Daignière wrote:
> * Matthew Toseland <[EMAIL PROTECTED]> [2008-03-18 18:12:39]:
>
> > On Sunday 16 March 2008 12:14, [EMAIL PROTECTED] wrote:
> > > Author: nextgens
> > > Date: 2008-03-16 12:14:56 + (Sun, 16 Mar 2008)
> > > New Revision: 18552
> > >
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/2b979ead/attachment.pgp>
safe-mode.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/5cb63615/attachment.pgp>
http://127.0.0.1:/
> > + at goto doneURL
> > +:withURL
> > + at set URL=%1
> > +:doneURL
> >
> > :: Check the simple case first (FF exists and has been detected)
> > @if not exist firefox.location goto detectff
-- next part --
A n
ignature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080319/346f1bd0/attachment.pgp>
Hi,
I'm a french student of computer science at ENSIMAG[1]. I am looking for
your feeling
on my proposal for working in your organization as part of the Google
Summer of Code.
I have been using the Freenet software for various reasons for a long time
and I find
it to be a very interesting endea
36 matches
Mail list logo
