Oskar Sandberg <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2001 at 11:28:42PM -0500, Brandon wrote:
> > Actually, there is a full GPL-compatible servlet implementation. I opted
> > to instead use a super-minimal one (all options to /dev/null, as Oskar
> > says) which I wrote from scratch in 5 minutes. I did this because of the
> > fear of "bloat" when including a servlet API. The plan was to paste in the
> > code from the GPLed servlet API whenever more of the API was needed.
>
> I don't quite see how this relates. My objection to the use of the
> servlet in Fred was that it was taking arbitrary TCP streams and
> wrapping them as servlets in order to have the hendled - which _is_
> bloat because java.net.Socket (or Freenet.Connection) object contains
> all the information that a TCP connections provides. Servlets are used
> for HTTP servers, and wrap the application level request, and therefore
> contain a bunch of information methods to describe the application level
> options.
>
> Putting an API for Fred to call Servlets makes no sense because there is
> no reason to be able to plug in arbritrary servlets into Fred, and
> unless you want to turn Fred in a full fledged web server there never
> was.
I haven't looked at the servlet stuff, so I don't really have an opinion
about whether it belongs, but I did have some intentions to turn fproxy
into - not exactly a full web server, but a full proxy server. That is,
all your normal HTTP requests as well as your Freenet requests would pass
through fproxy. Then you would be able to catch anonymity-compromising
stuff better, and you could do more rewriting on Freenet URL's.
> OTOH, using servlets internally in fproxy to handle the HTTP requests
> (parsing the HTTP request options into the servlet options) is a
> different matter. If you did that, then the servlet part of fproxy could
> plug into apache and other servers that run serverlets, which might be
> useful - something that, unless I have misread the code gravely, could
> not work today because the internals of fproxy expect to find HTTP
> headers on the stream after the servlet is handled. That is internal to
> fproxy however, such a servlet structure should not be visible to Fred's
> core.
That's another thought. However, I don't see how to reconcile this with an
internal interface between fproxy and Fred. Either they communicate
through shared memory, or they use sockets. If fproxy changes to use an
internal interface, it is obviously no longer usable as an Apache servlet,
unless you bring all of Fred into Apache as a servlet as well. (Although
that might be an interesting possibliity too - imagine if every Apache
webserver in the world came with Freenet by default.)
theo
PGP signature
