> 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.
Yet another Freenet-specific architecture that people have to learn is the
last thing we need. We should stick to a standard API that already has
lots of documentation and tutorials and even books about it, one which
people already know and can use.
The servlet API looks bulky because hardly any of its useful features have
been used yet. What we should do is include a full implementation in a
library and start using all of its features. My minimalist implementation
was just a placeholder so that would could start writing plugins right
now.
> The only thing that really matters about the servlet API is that you can
> write a class that will run as a plug-in to the node that implements this
>
> So why don't we just do it this way?
That's all that's being used write now, but that will suddenly change as
soon as we start writing HTTP-based node plugins. It was one thing to
write a single one (most of the code was already written when I got to
it), but it's just ridiculous to write 3 (that's how many are proposed
right now) HTTP-based plugins and not use the standard API for doing so.
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
