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. > > 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. > > That was the entire plan behind using stuff like the Servlet API and > SimplifiedClient, saving coding time and minimizing the stuff you need to > change between versions of the node. > > I would like to integrate a full version of the servlet API with the > HTTPServlet stuff and rip the HTTP stuff out of FProxy and use the > HTTPServlet stuff instead. I didn't do this because the FProxy HTTP stuff > was written and I didn't want people to complain about bloat from adding > the HTTPServlet stuff. However, if someone did that it would be way cool > because then FProxy would be really tiny. > > However, the 0.4 developers want to rewrite the code to use these new > APIs. That's why I'm not working on FProxy anymore. I spent my time > implementing a highly abstract client interface and integrating a standard > service interface specifically so I wouldn't have to rewrite my code every > time a new node version comes out. I'm not going to spend my time > unnecessarily reimplementing things. But I think things will eventually be > reimplemented to the new APIs, so I won't waste my time working on the > current version of FProxy which will eventually be scrapped.
You have a flair for drama, my friend. I should mention that porting fproxy to the 0.4 plug-in API should take like 5 minutes. Getting intelligent metadata handling out of SimplifiedClient could be an endless turmoil, however.. -- # 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
