> Well, this is getting scary.  Now we have 3 volunteers to work on the
> new fproxy...

Now Theodore is back on the case, I'll withdraw from the new FProxy project,
unless invited otherwise.

Let's all welcome and encourage Theodore in writing the new 0.4 fproxy.

Cheers
David

----- Original Message -----
From: "Tavin Cole" <[email protected]>
To: <devl at freenetproject.org>
Sent: Friday, June 22, 2001 15:34
Subject: Re: [freenet-devl] FProxy must die^H^H^Hget fixed!


> Well, this is getting scary.  Now we have 3 volunteers to work on the
> new fproxy...
>
> On Fri, Jun 22, 2001 at 01:19:35AM +0200, Oskar Sandberg wrote:
> > On Thu, Jun 21, 2001 at 09:06:07PM +0100, Theodore Hong wrote:
> > <>
> > > I've actually started to have some more time now, so I was planning on
> > > coming back into development a bit instead of just writing papers. =)
> > > Which are the main classes to look at where you've started to do work
> > > on this already?
> >
> > The stuff I did back then is in Freenet.node.interfaces.http (you'll
> > need to move the experimental branch). I'm not sure that it is useful
> > though, we changed the way the Interfaces are defined since I wrote
> > that, so it won't even compile (the Util class has a multipart splitting
> > method though - and one that doesn't split the data into Strings as to
> > boot! I was told later that the correct way of doing that is with a
> > rolling hash value, so it could be nicer).
>
> Huh?
>
> > It could probably be argued successfully that my attempt to use the
> > Freenet classes (RawMessage etc) to read http messages was misguided.
> > The option is to write a new implementation of Freenet.Interface that
> > overrides the getERunnable() method with something that returns a Thread
> > that handles the HTML connection in whatever manner you see fit. We'll
> > probably connect an implementation of Freenet.client.InternalClient
> > to the Freenet.node.Node so that can be used for requests...
>
> There is no need to write any new implementation of Freenet.Interface.
> Instead, you should write an implementation of Freenet.FreenetServlet
> -- this is a one method interface:
>
>     void service(Node node, InputStream in, OutputStream out)
>         throws Throwable;
>
> Inside this method, you would do:
>
>     ClientFactory cf = new InternalClient(node);
>     AutoClient ac    = new AutoClient(cf, ...);
>     // (the AutoClient API is still in flux)
>
> And then, use the AutoClient to do the request and write the results
> back to the output stream..
>
> Now, the only other wrinkle is how this class will be constructed.
> There would be something in the config file like:
>
>     services.fproxy.class=Freenet.client.http.HTTPServlet
>     services.fproxy.port=8081
>     [services.fproxy.bindAddress=...]
>     [services.fproxy.allowedHosts=...]
>     [services.fproxy.additionalParam1=...]
>     [services.fproxy.additionalParam2=...] etc.
>
> Whenever there is a connection to handle on port 8081,
> Freenet.client.http.HTTPServlet would be constructed with a single
> argument to the constructor: a FieldSet containing the additionalParam
> entries.  Then the service() method would be called.
>
> --
>
> # tavin cole
> #
> # "Technology is a way of organizing the universe so that
> # man doesn't have to experience it."
> #
> #        - Max Frisch
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://lists.freenetproject.org/mailman/listinfo/devl
>


_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl

Reply via email to