> The funny thing about the servlet API in 0.3 Fred is that, while > arguments are floated about how it's good because it's a standard, > the fact is we don't correctly implement the standard -- we only use > about 1% of it.
You misunderstand the purpose. The purpose is to have a standard interface. To this effect, all that is needed is to have the servlet jar which gives us the interfaces so that you can implement a standard interface. Unfortunately, Ian has set up a policy of never using libraries. Because of this, I had to implement a minimalistic implementation of the interface. I would love to replace my minimalist implementation with a full implementation if we ever abandonded our no-libraries policy. > This is just the tip of the iceberg. If you read over this you get the > idea that, "Hey there's a whole lot of completely unused baggage in here > meant for the traditional HTTP web-application environment." Try looking > at the other classes in Freenet.servlet -- it gets worse. We've gotten to the point that we are about to start implementing several HTTP-based plugins. People have been talking about "extending" FProxy to do things like insertion wizards and node control and configuration. This is when we'll need the HTTP-specific capabilities of the servlet API. Rather than cramming a lot of unrelated functionality into FProxy, the proper approach is to write several HTTP servlets for the different functions. > As has been discussed, the servlet API in its 0.3 form had to be at least > temporarily discarded while developing 0.4. Before we bring back this > hulking, klunky beast, let's consider using a much simpler plug-in model.
