189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20020912/9f22f076/attachment.pgp>
n the fly.
--
Robbe
-- next part --
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20020912/3e6a72f3/attachment.pgp>
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate "data blocks"
and "check blocks"? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it (you need any k
blocks of n in order to decode a file).
Freenet Project Inc. from 11/9/02 to 11/11/02.
-- 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/20020912/bbda5481/attachment.pgp>
s having two
> encoders, given that the facilities are there, and let the best codec win
> :-p.
>
>
>
--
Matthew Toseland
mtoseland at blueyonder.co.uk
amphibian at sourceforge.net
Freenet/Coldstore open source hacker.
Employed full time by Freenet Project Inc. from 11/9/02 to 1
time by Freenet Project Inc. from 11/9/02 to 11/11/02.
-- 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/20020912/b780a2ef/attachment.pgp>
On Thursday 12 September 2002 08:42, you wrote:
> However, you were never able to insert a *site* by fproxy. This would be
> a useful feature, no? :)
This is exactly the kind of feature that doesn't belong in a bloated
monolithic fproxy, but which could easily be implemented as a separate
On Thursday 12 September 2002 08:40, you wrote:
> > Anyhow, the other point I wished to make, is that from looking at your
> > information, it seems like it would be far more convinent still to just
> > call the onionnetworks library direclty - okay, yeah, I see the
> > usefulness of this for
On Thursday 12 September 2002 05:37, you wrote:
> Most of this sounds pretty good.
>
> Firstly, a stupid question - is there any reason to seperate "data blocks"
> and "check blocks"? As far as the FEC encoder/decoder knows, they're just
> blocks, right? I mean, that's the whole *point* of it
None follow Ian's call for opinion about the
fproxy insertion capability removal.
My opinion about it is that was a bad(TM) idea.
I cannot imagine a good technical reason for that.
From a normal user point of view, this fact transform
a read/write media in a readonly media; something that
ge http://locut.us/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20020912/55b2a7fb/attachment.pgp>
il/devl/attachments/20020912/b0d0c055/attachment.pgp>
FCP FEC Proposal rev. 1.0
giannijohansson at attbi.com 20020912
I. INTRODUCTION:
This proposal presents a set of new FCP commands that can be used to
encode and decode files using forward error correction (FEC).
FEC is a way of encoding packetized data files with extra error
recovery
I think we should break froxy up into separate servlets bound together on the
same port with Tavin's MultipleHttpServletContainer. The hard cross port
redirects are ugly. Once everything is running on the same port redirects
are less ugly.
/ -- with no arguments would map to Ian's infolet
ould
just decompile. We have full human readable source to all the tricky stuff.
-- next part --
A non-text attachment was scrubbed...
Name: FCP-FEC.txt
Type: text/english
Size: 9272 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attach
None follow Ian's call for opinion about the
fproxy insertion capability removal.
My opinion about it is that was a bad(TM) idea.
I cannot imagine a good technical reason for that.
From a normal user point of view, this fact transform
a read/write media in a readonly media; something that
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate data blocks
and check blocks? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it (you need any k
blocks of n in order to decode a file).
On Thu, Sep 12, 2002 at 02:24:28AM -0400, Gianni Johansson wrote:
I think we should break froxy up into separate servlets bound together on the
same port with Tavin's MultipleHttpServletContainer. The hard cross port
redirects are ugly. Once everything is running on the same port
On Thu, Sep 12, 2002 at 07:37:32PM +1000, fish wrote:
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate data blocks
and check blocks? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it
On Thu, Sep 12, 2002 at 10:31:58AM +0200, Marco A. Calamari wrote:
None follow Ian's call for opinion about the
fproxy insertion capability removal.
My opinion about it is that was a bad(TM) idea.
I cannot imagine a good technical reason for that.
From a normal user point of view,
On Thursday 12 September 2002 05:37, you wrote:
Most of this sounds pretty good.
Firstly, a stupid question - is there any reason to seperate data blocks
and check blocks? As far as the FEC encoder/decoder knows, they're just
blocks, right? I mean, that's the whole *point* of it (you need
On Thursday 12 September 2002 08:40, you wrote:
Anyhow, the other point I wished to make, is that from looking at your
information, it seems like it would be far more convinent still to just
call the onionnetworks library direclty - okay, yeah, I see the
usefulness of this for providing
On Thursday 12 September 2002 08:42, you wrote:
However, you were never able to insert a *site* by fproxy. This would be
a useful feature, no? :)
This is exactly the kind of feature that doesn't belong in a bloated
monolithic fproxy, but which could easily be implemented as a separate
As of this email, FProxy can insert again (I have updated the snapshot).
Ian.
--
Ian Clarke[EMAIL PROTECTED]
Founder Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc. http://www.uprizer.com/
On Thu, Sep 12, 2002 at 10:31:58AM +0200, Marco A. Calamari wrote:
I cannot imagine a good technical reason for that.
It was a usability reason, FProxy should be a tool for retrieval of
information from Freenet, there are much better tools for inserting
information into Freenet.
From a
Gianni Johansson [EMAIL PROTECTED] writes:
It's good to make the distinction because if you manage to get all the data
blocks you don't need to decode at all.
Prefering data blocks to check blocks will restrict the usefulness of
FEC, as it will make the check blocks less popular, thus less
Gianni Johansson [EMAIL PROTECTED] writes:
/ -- with no arguments would map to Ian's infolet main page
-- with a valid URI, maps to a leaner and meaner fproxy-lite servlet that
handles normal requests and inserts but redirects splitfile
inserts /requests to he servlets
On Thu, 12 Sep 2002, Ian Clarke wrote:
Not at all, it just means that they can't insert with FProxy, I honestly
doubt many people were actually using FProxy for inserting stuff (more
likely they will use fcptools, freeweb, or frost).
You'd be surprised, actully, at how many people were
On Thu, 12 Sep 2002, Gianni Johansson wrote:
It's good to make the distinction because if you manage to get all the data
blocks you don't need to decode at all.
bob the angry flower says wrong,m wrong, wrong ,wrong, where did you
learn that??! wrong!!! :-p. Seriously, this is a very bad
29 matches
Mail list logo
