[freenet-dev] Killing the datastore bug

[Ian Clarke]

Additionally, looking at the number of "Cache failed" errors in the
logs, and assuming these are also caused by datastore problems, I 
suspect we will see a rather dramatic improvement in performance once 
we resolve the remaining datastore issues.

Ian.

On Wed, Sep 04, 2002 at 06:52:40PM -0700, Ian Clarke wrote:
> It his high-time we took concerted action to kill the datastore bug.
> 
> The options are:
> 
>  - Someone figures out how Tavin's datastore works and debugs it
>  - We reimplement it
> 
> I am aware that someone is working on a native datastore 
> implementation, and am curious about how they are progressing, but 
> what about the problem we experienced last time (ie. the JVM not 
> deleting files when it was supposed to on some operating systems 
> leading to hard disks getting filled up)?
> 
> Failing that, we could implement a single-file datastore, but attempt 
> to avoid the complexity of the current implementation.
> 
> Thoughts?
> 
> Ian.
> 
> -- 
> Ian Clarkeian at freenetproject.org
> Founder & Coordinator, The Freenet Projecthttp://freenetproject.org/
> Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
> Personal Homepage http://locut.us/



-- 
Ian Clarkeian at freenetproject.org
Founder & Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   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/20020904/826be4d6/attachment.pgp>

[freenet-dev] Fproxy changes

[Ian Clarke]

Well, in theory - yes, in practice, it ain't so easy.

The NodeInfoServlet resides on port 8890, that is the thing that draws the nice 
menu to the left, and can't really support controlling of the entire 
web-browser window, which is why we need FProxy.

Now, we could - say - set it up so that going to :

http://localhost:8890/fproxy/CHK%40...

Works like going to:

http://localhost:/CHK%40...

does now - however we would no-longer be able to take advantage of links to the 
server root (ie. hyperlinks which begin with "/").  That would be unfortunate.

I guess we could also determine in real-time whether the URL looks like an 
FProxy link, or whether it looks like a NodeInfoServlet link.

Ian.

On Wed, Sep 04, 2002 at 11:27:22PM -0400, Dan Merillat wrote:
> Ok, let it be said I love the new UI.  However, since : is just 
> redirecting
> to :8890, can't we just merge the two interfaces?
> 
> It screws up my setup of using squid to redirect freenet requests, but I 
> think I
> can work around it.  Perhaps.  It's a pain to rewrite URLs on the fly, so I 
> may have
> to maintain diffs to the source (UGH).

-- 
Ian Clarkeian at freenetproject.org
Founder & Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   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/20020904/b16cb37d/attachment.pgp>

[freenet-dev] Major fproxy changes

[Ian Clarke]

Those who try the current snapshot will now notice that the 
gateway.html page is now replaced by an Infolet.

Only the basics are there right now, but people are invited to 
improve it and tidy it up.

The code for the new gateway infolet can be found in 
freenet/src/freenet/node/http/infolets/DefaultInfolet.java

Ian.

-- 
Ian Clarkeian at freenetproject.org
Founder & Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   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/20020904/5c0e0cfd/attachment.pgp>

[freenet-dev] IE and the anonymity filter... big trouble

[Matthew Toseland]

Committed a fix... we warn IE users, once per IP address, about this.
-- 
Matthew Toseland
mtoseland at blueyonder.co.uk
amphibian at sourceforge.net
Freenet/Coldstore open source hacker.
Looking for $coding.
-- 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/20020904/0ba29411/attachment.pgp>

[freenet-dev] Fixing spurious filter warnings

[Benjamin Coates]

>From Gianni Johansson  
[...]
>> > or maybe something like this since DBR's can have periods shorter than 1
>> > day.
>> >
>> > /__DATE__MMDDHHMM/SSK%40rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/TFE//
>>
>> It's ugly. Really really ugly.
>I don't think it's ugly or I wouldn't have suggested it.  However if you are
>willing to implement it, I don't care how you do it as long as you don't
>change the anonymity filter.
>
>You do probably want minute resolution for the DBR time though.
>
>--gj

Didn't we go over this some months ago?  I'm having trouble finding it in the 
archives (or even reasonably complete archives at all), but I thought there 
was agreement on something along the lines of 
freenet:ssk at 40rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/[MMDD]TFE//

I'm not sure about what sort of format we wanted between the brackets, I was 
in favor of just using a java port of getdate (which I have laying around here 
somewhere) but I don't know if that went over well or what.

--
Benjamin Coates


___
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] FEC Implementation

[Matthew Toseland]

On Tue, Sep 03, 2002 at 10:28:07PM -0400, Gianni Johansson wrote:
> On Tuesday 03 September 2002 21:06, you wrote:
> > Can anyone suggest good reading material so I can implement FEC
> > transparently in FCPTools?  I've found material on the web so far
> > (search terms "forward error correction"), but anything else will be
> > appreciated.
> >
> > Thank you.
> 
> 0) FCP 
> I am working on FCP support for FEC encoding/files files. I should have it 
> workin within a week or so.
doublepluscool. Another major item off the todo list. Lets hope Frost
decides to use it.
> 
> 1) Native C
> You can rip the native FEC encoder and decoder implementations out of the 
> onion networks distribution.  I think that's what fish did. 
> 
> http://www.onionnetworks.com/rm/index.html#fec
> 
> 
> --gj

-- 
Matthew Toseland
mtoseland at blueyonder.co.uk
amphibian at sourceforge.net
Freenet/Coldstore open source hacker.
-- 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/20020904/4fc93b7b/attachment.pgp>

[freenet-dev] data store bug

[Greg Wooledge]

So, the CofE/TFE/FF author wants details on the data store bug.  Well,
I don't use Frost, so I'll write it out here in the open where normal
people can read it.

There has been some speculation that Frost causes the DSB.  I can't
confirm that.  I have *never* used Frost, and probably never will,
and I've seen the DSB quite a few times, especially recently.  So
it's not *unique* to Frost, though I can't say whether running Frost
might increase its likelihood.

Some people have said the DSB only shows up when Freenet is stopped.
Oskar (hobx) claims that's not the case; the DSB actually happens,
stealthily, while the node is running.  You just don't know about it
until you try to restart the node and can't do so.

(Actually, that's not the only symptom.  The other symptom, for a node
that's been DSB'd but not stopped yet, is that requests for information
go unsatisfied -- either it doesn't answer, or it gives back blank
pages.  "Document contains no data" errors in the browser, for example.)

Some people say it happens when the data store fills up.  Or when one
file of a multiple-file data store fills up.  Well, hawk.freenetproject.org
is running a 10 MB data store (yes, 10 *mega* bytes, that's not a typo)
and apparently it doesn't get DSB'd, or at least not commonly.

Someone in IRC (I believe it was Pascal) said that the DSB is usually
caused by the Java VM running out of memory.  As far as I can tell,
he's right.  If you check your node's logs after noticing a DSB,
chances are you'll see an "OutOfMemory" error message.

I'm unclear on just why a Java VM would get this.  It seems that they
(most of them) pre-allocate a large chunk of memory (64 MB), and then
dole this out to the application as it's needed.  But what happens
when that initial chunk is all used up?  Doesn't it allocate more?
Perhaps, perhaps not.  More importantly, if it can't/won't allocate
more memory, doesn't the application get some sort of error condition
that it can check?  In C, malloc() would return NULL.  I have no
idea what the Java equivalent of that is.  But it's clear to me that
when the JVM runs out of memory, Freenet is *not* handling it
gracefully.

The workaround that Pascal(?) has suggested is to raise the amount
of memory the Java VM is permitted to use.  This seems to require
two steps:

 1) On the java command line that starts Freenet (usually in a shell
script), add a parameter which tells the Java VM to request more
memory.  E.g., on Kaffe, this is "-mx".

 2) Within the operating system environment, make sure that the amount
of memory the Java VM requests can actually be fulfilled.  This
may mean running "ulimit -d" to raise the maximum process data
segment size.  Kaffe will happily pre-allocate 256 MB even if
the data segment size is limited to less than that; but if you
actually *use* that much memory, *blam*, DSB time.

What may be needed is a thorough code audit to add error checking to
the Freenet node, so that it doesn't puke when memory is exhausted.
Either that, or make it use less memory in the first place.  I'm no
Java programmer, so I'll leave that one alone.

As an end user, one thing that *might* work to decrease the amount of
memory used by the node is to lower the number of threads it's allowed
to use.  On the other hand, when I asked the developers how many open
files the node uses, as a function of the number of threads, I was
greeted by a looming silence.  Read what you will into that.

The DSB might be more common with some Java VM implementations than
with others.  Kaffe seems to be more aggressive in its memory use
than the Sun JRE, but then again, I haven't conducted a rigorous
investigation yet.  It's *REALLY* hard to do this when Sun's
"write once run anywhere" solution doesn't *ACTUALLY* run anywhere.
It only runs on Windows, Solaris and Linux.  That leaves a lot of
us out in the cold

Finally, some people have suggested backing up the data store periodically,
so that it can be restored to its pre-DSB state.  This is a reasonable
suggestion, except that there's no deterministic way to know in
advance whether a given store file is DSB'd or not.  Backing up a
DSB'd store is a colossal waste of time and space, especially if you
overwrite a good backup with a bad one.  If you do this, you'll need
at least *two* backups, rotated, so that when you try to restart the
node after the backup, if you find that it's corrupt, you can restore the
good one, not the bad one you just created.

That's all for now.

-- 
Greg Wooledge  |   "Truth belongs to everybody."
greg at wooledge.org  |- The Red Hot Chili Peppers
http://wooledge.org/~greg/ |
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20020904/abdfc64b/attachment.pgp>

[freenet-dev] data store bug

[scgmi...@freenetproject.org]

> 
> I'm unclear on just why a Java VM would get this.  It seems that they
> (most of them) pre-allocate a large chunk of memory (64 MB), and then
> dole this out to the application as it's needed.  But what happens
> when that initial chunk is all used up?  Doesn't it allocate more?
> Perhaps, perhaps not.  More importantly, if it can't/won't allocate
> more memory, doesn't the application get some sort of error condition
> that it can check?  In C, malloc() would return NULL.  I have no
> idea what the Java equivalent of that is.  But it's clear to me that
> when the JVM runs out of memory, Freenet is *not* handling it
> gracefully.

The Sun JVM at least has a default max heap size of 64mb.  It does not
allocate this at start, but grows up to this limit.  Once its reached
it doesnt get anymore though.  This setting can be changed with 
-Xmxmb.

-- 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/20020904/ecb2c015/attachment.pgp>

[freenet-dev] IE and the anonymity filter... big trouble

[Robert Bihlmeyer]

Matthew Toseland  writes:

> We would have to filter ALL documents of supposedly safe types.

Reportedly MSIE only subjects text/plain and application/octet-stream
to the mime-type second-guessing. So an image/jpeg should be always
treated as an image, even if it looks like html. I have no Exploder
here to test that at the moment, though.

-- 
Robbe
-- next part --
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[freenet-dev] fproxy and fish fec tools.

[Robert Bihlmeyer]

Ian Clarke  writes:

> Isn't it time we turned on FEC by default, making it transparent for 
> our users to take advantage of it?

The FEC code in freenet-ext.jar is not GPL compatible.

-- 
Robbe
-- next part --
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[freenet-dev] data store bug

[Greg Wooledge]

So, the CofE/TFE/FF author wants details on the data store bug.  Well,
I don't use Frost, so I'll write it out here in the open where normal
people can read it.

There has been some speculation that Frost causes the DSB.  I can't
confirm that.  I have *never* used Frost, and probably never will,
and I've seen the DSB quite a few times, especially recently.  So
it's not *unique* to Frost, though I can't say whether running Frost
might increase its likelihood.

Some people have said the DSB only shows up when Freenet is stopped.
Oskar (hobx) claims that's not the case; the DSB actually happens,
stealthily, while the node is running.  You just don't know about it
until you try to restart the node and can't do so.

(Actually, that's not the only symptom.  The other symptom, for a node
that's been DSB'd but not stopped yet, is that requests for information
go unsatisfied -- either it doesn't answer, or it gives back blank
pages.  Document contains no data errors in the browser, for example.)

Some people say it happens when the data store fills up.  Or when one
file of a multiple-file data store fills up.  Well, hawk.freenetproject.org
is running a 10 MB data store (yes, 10 *mega* bytes, that's not a typo)
and apparently it doesn't get DSB'd, or at least not commonly.

Someone in IRC (I believe it was Pascal) said that the DSB is usually
caused by the Java VM running out of memory.  As far as I can tell,
he's right.  If you check your node's logs after noticing a DSB,
chances are you'll see an OutOfMemory error message.

I'm unclear on just why a Java VM would get this.  It seems that they
(most of them) pre-allocate a large chunk of memory (64 MB), and then
dole this out to the application as it's needed.  But what happens
when that initial chunk is all used up?  Doesn't it allocate more?
Perhaps, perhaps not.  More importantly, if it can't/won't allocate
more memory, doesn't the application get some sort of error condition
that it can check?  In C, malloc() would return NULL.  I have no
idea what the Java equivalent of that is.  But it's clear to me that
when the JVM runs out of memory, Freenet is *not* handling it
gracefully.

The workaround that Pascal(?) has suggested is to raise the amount
of memory the Java VM is permitted to use.  This seems to require
two steps:

 1) On the java command line that starts Freenet (usually in a shell
script), add a parameter which tells the Java VM to request more
memory.  E.g., on Kaffe, this is -mx.

 2) Within the operating system environment, make sure that the amount
of memory the Java VM requests can actually be fulfilled.  This
may mean running ulimit -d to raise the maximum process data
segment size.  Kaffe will happily pre-allocate 256 MB even if
the data segment size is limited to less than that; but if you
actually *use* that much memory, *blam*, DSB time.

What may be needed is a thorough code audit to add error checking to
the Freenet node, so that it doesn't puke when memory is exhausted.
Either that, or make it use less memory in the first place.  I'm no
Java programmer, so I'll leave that one alone.

As an end user, one thing that *might* work to decrease the amount of
memory used by the node is to lower the number of threads it's allowed
to use.  On the other hand, when I asked the developers how many open
files the node uses, as a function of the number of threads, I was
greeted by a looming silence.  Read what you will into that.

The DSB might be more common with some Java VM implementations than
with others.  Kaffe seems to be more aggressive in its memory use
than the Sun JRE, but then again, I haven't conducted a rigorous
investigation yet.  It's *REALLY* hard to do this when Sun's
write once run anywhere solution doesn't *ACTUALLY* run anywhere.
It only runs on Windows, Solaris and Linux.  That leaves a lot of
us out in the cold

Finally, some people have suggested backing up the data store periodically,
so that it can be restored to its pre-DSB state.  This is a reasonable
suggestion, except that there's no deterministic way to know in
advance whether a given store file is DSB'd or not.  Backing up a
DSB'd store is a colossal waste of time and space, especially if you
overwrite a good backup with a bad one.  If you do this, you'll need
at least *two* backups, rotated, so that when you try to restart the
node after the backup, if you find that it's corrupt, you can restore the
good one, not the bad one you just created.

That's all for now.

-- 
Greg Wooledge  |   Truth belongs to everybody.
[EMAIL PROTECTED]  |- The Red Hot Chili Peppers
http://wooledge.org/~greg/ |



msg03782/pgp0.pgp
Description: PGP signature

Re: [freenet-dev] data store bug

[scgmille]

 
 I'm unclear on just why a Java VM would get this.  It seems that they
 (most of them) pre-allocate a large chunk of memory (64 MB), and then
 dole this out to the application as it's needed.  But what happens
 when that initial chunk is all used up?  Doesn't it allocate more?
 Perhaps, perhaps not.  More importantly, if it can't/won't allocate
 more memory, doesn't the application get some sort of error condition
 that it can check?  In C, malloc() would return NULL.  I have no
 idea what the Java equivalent of that is.  But it's clear to me that
 when the JVM runs out of memory, Freenet is *not* handling it
 gracefully.

The Sun JVM at least has a default max heap size of 64mb.  It does not
allocate this at start, but grows up to this limit.  Once its reached
it doesnt get anymore though.  This setting can be changed with 
-Xmxnmb.




msg03783/pgp0.pgp
Description: PGP signature

Re: [freenet-dev] IE and the anonymity filter... big trouble

[Matthew Toseland]

Committed a fix... we warn IE users, once per IP address, about this.
-- 
Matthew Toseland
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Freenet/Coldstore open source hacker.
Looking for $coding.



msg03784/pgp0.pgp
Description: PGP signature

RE: [freenet-dev] Fixing spurious filter warnings

[Benjamin Coates]

From Gianni Johansson [EMAIL PROTECTED] 
[...]
  or maybe something like this since DBR's can have periods shorter than 1
  day.
 
  /__DATE__MMDDHHMM/SSK%40rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/TFE//

 It's ugly. Really really ugly.
I don't think it's ugly or I wouldn't have suggested it.  However if you are
willing to implement it, I don't care how you do it as long as you don't
change the anonymity filter.

You do probably want minute resolution for the DBR time though.

--gj

Didn't we go over this some months ago?  I'm having trouble finding it in the 
archives (or even reasonably complete archives at all), but I thought there 
was agreement on something along the lines of 
freenet:ssk@40rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/[MMDD]TFE//

I'm not sure about what sort of format we wanted between the brackets, I was 
in favor of just using a java port of getdate (which I have laying around here 
somewhere) but I don't know if that went over well or what.

--
Benjamin Coates


___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Attention Pascal: box.tpl screwy

[Ian Clarke]

Pascal, I think the modification you made to the box template has 
screwed it up.  It now appears to have some kind of border at the top 
and the bottom, see a screenshot at:
  http://hawk.freenetproject.org/~ian/screwybox.png

If you can't fix this, I will have to revert to the previous revision.

Ian.

-- 
Ian Clarke[EMAIL PROTECTED]
Founder  Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   http://locut.us/



msg03786/pgp0.pgp
Description: PGP signature

Re: [freenet-dev] HTML/CSS parser?

[Matthew Toseland]

On Thu, Sep 05, 2002 at 01:02:26AM +0100, Matthew Toseland wrote:
 Does anyone know of an HTML+CSS parser written in java that we could
 borrow? Maybe from a java web browser? Or maybe we could convert
 something from C[++]/flex?
 
It looks to me like we :) are going to have to write a more or less
full HTML/CSS/CSS2 parser in jflex... oh well, it's only 91 elements
(for HTML4.01... then there's CSS). Having reasonable assurance of not
receiving anonymity-compromizing HTML in fproxy is an important part of
freenet in its current form.

-- 
Matthew Toseland
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Freenet/Coldstore open source hacker.
Looking for $coding (I'm cheap)



msg03788/pgp0.pgp
Description: PGP signature

[freenet-dev] Major fproxy changes

[Ian Clarke]

Those who try the current snapshot will now notice that the 
gateway.html page is now replaced by an Infolet.

Only the basics are there right now, but people are invited to 
improve it and tidy it up.

The code for the new gateway infolet can be found in 
freenet/src/freenet/node/http/infolets/DefaultInfolet.java

Ian.

-- 
Ian Clarke[EMAIL PROTECTED]
Founder  Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   http://locut.us/



msg03789/pgp0.pgp
Description: PGP signature

Re: [freenet-dev] Fixing spurious filter warnings

[Matthew Toseland]

On Wed, Sep 04, 2002 at 03:28:51PM -0400, Benjamin Coates wrote:
 From Gianni Johansson [EMAIL PROTECTED] 
 [...]
   or maybe something like this since DBR's can have periods shorter than 1
   day.
  
   /__DATE__MMDDHHMM/SSK%40rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/TFE//
 
  It's ugly. Really really ugly.
 I don't think it's ugly or I wouldn't have suggested it.  However if you are
 willing to implement it, I don't care how you do it as long as you don't
 change the anonymity filter.
 
 You do probably want minute resolution for the DBR time though.
 
 --gj
 
 Didn't we go over this some months ago?  I'm having trouble finding it in the 
 archives (or even reasonably complete archives at all), but I thought there 
 was agreement on something along the lines of 
 freenet:ssk@40rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/[MMDD]TFE//
 
 I'm not sure about what sort of format we wanted between the brackets, I was 
 in favor of just using a java port of getdate (which I have laying around here 
 somewhere) but I don't know if that went over well or what.
We have implemented /SSK@blah/blah?date=MMDD[-HH:MM:SS] 

([] meaning optional) - a very rigid format, but not a difficult one to
write or to parse. Hopefully we can just unblock ?'s, and this will
just work (or we could only allow certain safe parameters to relative
links, ?date being the main one).
 
 --
 Benjamin Coates
 

-- 
Matthew Toseland
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Freenet/Coldstore open source hacker.
Looking for $coding (I'm cheap)



msg03790/pgp0.pgp
Description: PGP signature

[freenet-dev] Killing the datastore bug

[Ian Clarke]

It his high-time we took concerted action to kill the datastore bug.

The options are:

 - Someone figures out how Tavin's datastore works and debugs it
 - We reimplement it

I am aware that someone is working on a native datastore 
implementation, and am curious about how they are progressing, but 
what about the problem we experienced last time (ie. the JVM not 
deleting files when it was supposed to on some operating systems 
leading to hard disks getting filled up)?

Failing that, we could implement a single-file datastore, but attempt 
to avoid the complexity of the current implementation.

Thoughts?

Ian.

-- 
Ian Clarke[EMAIL PROTECTED]
Founder  Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   http://locut.us/



msg03791/pgp0.pgp
Description: PGP signature

[freenet-dev] Fproxy changes

[Dan Merillat]

Ok, let it be said I love the new UI.  However, since : is just redirecting
to :8890, can't we just merge the two interfaces?

It screws up my setup of using squid to redirect freenet requests, but I think I
can work around it.  Perhaps.  It's a pain to rewrite URLs on the fly, so I may have
to maintain diffs to the source (UGH).

--Dan


___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Is anyone alive

[Dan Merillat]

Ian Clarke writes:
 
 --gKMricLos+KVdGMg
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 Christ, no matter what horrible mutilations of the code I wilfully admit=20
 on this mailing list, I still fail to provoke a reaction...  does anyone=20
 read this stuff any more?  (:-P)P)
 
Here, I do.  As I said, the interface is pretty, but the absolute URL redirects
have GOT to go. It screwed up my ability to use freenet until I can make some changes.
(Actually, I take that back, I just have to paste URLs to :)
Putting the two things together make sense, since key retrieval is a well-defined 
interface. 

--Dan

___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Depreciating Makefile

[Dan Merillat]

Matthew Toseland writes:
 
 --6TrnltStXW4iwmi0
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Aug 29, 2002 at 11:59:50AM -0700, Ian Clarke wrote:
  I would like to encourage those still using the Makefile and make to=20
  switch to Ant (downloadable from http://jakarta.apache.org/ant/),=20
  as it is a pain to have to update both Makefile and build.xml when=20
  modifications are made, and Ant is more powerful, and easier to=20
  use than make.
 More powerful than GNU make? That's difficult to believe... but we don't
 use make as make, we basically call a shell script.

The problem with make is javac has a stupid startup time, so is best called with 30+ 
files at
once.  Make likes to call things sequentially.  ant is designed to call javac once with
all the filenames.

Make can be hacked into creating a list of 'updated' files, but it's not worth it.

--Dan


___
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Fproxy changes

[Ian Clarke]

Well, in theory - yes, in practice, it ain't so easy.

The NodeInfoServlet resides on port 8890, that is the thing that draws the nice 
menu to the left, and can't really support controlling of the entire 
web-browser window, which is why we need FProxy.

Now, we could - say - set it up so that going to :

http://localhost:8890/fproxy/CHK%40...

Works like going to:

http://localhost:/CHK%40...

does now - however we would no-longer be able to take advantage of links to the 
server root (ie. hyperlinks which begin with /).  That would be unfortunate.

I guess we could also determine in real-time whether the URL looks like an 
FProxy link, or whether it looks like a NodeInfoServlet link.

Ian.

On Wed, Sep 04, 2002 at 11:27:22PM -0400, Dan Merillat wrote:
 Ok, let it be said I love the new UI.  However, since : is just redirecting
 to :8890, can't we just merge the two interfaces?
 
 It screws up my setup of using squid to redirect freenet requests, but I think I
 can work around it.  Perhaps.  It's a pain to rewrite URLs on the fly, so I may have
 to maintain diffs to the source (UGH).

-- 
Ian Clarke[EMAIL PROTECTED]
Founder  Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   http://locut.us/



msg03795/pgp0.pgp
Description: PGP signature

Re: [freenet-dev] Killing the datastore bug

[Ian Clarke]

Additionally, looking at the number of Cache failed errors in the
logs, and assuming these are also caused by datastore problems, I 
suspect we will see a rather dramatic improvement in performance once 
we resolve the remaining datastore issues.

Ian.

On Wed, Sep 04, 2002 at 06:52:40PM -0700, Ian Clarke wrote:
 It his high-time we took concerted action to kill the datastore bug.
 
 The options are:
 
  - Someone figures out how Tavin's datastore works and debugs it
  - We reimplement it
 
 I am aware that someone is working on a native datastore 
 implementation, and am curious about how they are progressing, but 
 what about the problem we experienced last time (ie. the JVM not 
 deleting files when it was supposed to on some operating systems 
 leading to hard disks getting filled up)?
 
 Failing that, we could implement a single-file datastore, but attempt 
 to avoid the complexity of the current implementation.
 
 Thoughts?
 
 Ian.
 
 -- 
 Ian Clarke[EMAIL PROTECTED]
 Founder  Coordinator, The Freenet Projecthttp://freenetproject.org/
 Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
 Personal Homepage http://locut.us/



-- 
Ian Clarke[EMAIL PROTECTED]
Founder  Coordinator, The Freenet Projecthttp://freenetproject.org/
Chief Technology Officer, Uprizer Inc.   http://www.uprizer.com/
Personal Homepage   http://locut.us/



msg03797/pgp0.pgp
Description: PGP signature

Re: [freenet-dev] Killing the datastore bug

[Tracy R Reed]

On Wed, Sep 04, 2002 at 06:52:40PM -0700, Ian Clarke spake thusly:
 It his high-time we took concerted action to kill the datastore bug.

Glory glory hallelujah!

Next time my datastore tosses its cookies what should I do? What
information do you need? I'd like to help however possible.

  - Someone figures out how Tavin's datastore works and debugs it

Not a bad idea. Did Tavin get hit by a bus or something?

  - We reimplement it

If someone else is working on a native datastore then I would suggest
letting them do their thing while we figure out what's wrong with the
current datastore. The question should be this: Is Tavin's design good and
worth salvaging or is it poorly designed and bound to be full of problems
forever?

 Failing that, we could implement a single-file datastore, but attempt 
 to avoid the complexity of the current implementation.

Isn't a single file datastore quite hard to debug? I'm always a fan of not
reinventing the wheel so it would seem wise to let native filesystems do
as much as possible.

-- 
Tracy Reed  http://www.ultraviolet.org



msg03798/pgp0.pgp
Description: PGP signature