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 oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
