On Thu, Jun 21, 2001 at 11:28:42PM -0500, Brandon wrote:
>
> > ok, fine. What options do you want to handle? The only one I can think of
> > that makes sense in this context is Range.
>
> 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.
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.
> You could, of course, just replace my minimalist implementation with the
> full GPLed servlet library.
>
> You don't need to rewrite FProxy for 0.4 at all. You don't need to change
> even one line of code for FProxy to work with 0.4. FProxy uses the
> standard Servlet API (standard, so it doesn't change for 0.4) and
> SimplifiedClient (abstracted *specifically* so you don't have to rewrite
> any of your code for 0.4). All you need to do is modify SimplifiedClient
> to instantiated the internal access API version of the Client handler
> rather than the FNP one. Voila, FProxy that works with 0.4 with no changes
> to FProxy at all.
You are right, you don't. And the truth is that the lower Client
interface has stayed more or less the same as well, so you could have
moved it without writing many lines of code even if you had never
abstracted that. And Tavin's Freenet servlet interface, which is:
void service(Node node, InputStream in, OutputStream out) throws Throwable;
is (obviously) exactly the way that interface would have been had it
been written for 0.3, so that would not have mandated a rewrite either.
But changes in the interface is not why I want to rewrite the nodes http
interface for 0.4. I want it rewritten because the current
implementation has issues. And you can Theo can be defensive about that
if you like, but the truth is that we have rewritten a ton of my code as
well, because it too, had issues (this includes the _entire_ application
level protocol implementation).
You know, if we wanted to, we could put out the next version of Freenet
by rewriting just a single line - the version number.
<>
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
[EMAIL PROTECTED]
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
