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
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
