In short, I am very skeptical that you'll find a way to use the HTTP-centric
functionality of the servlet API in a way that makes sense within Fred.
But if you want to try, go for it :)
For a number of reasons the layering _between_ Fred and the servlet API
needed to change anyway. So I have created a very minimalist plug-in model
in 0.4. You must write a class that implements Freenet.FreenetServlet,
which has one method:
public void service(Node n, InputStream in, OutputStream out)
throws Throwable;
Also, when the Node is constructed, it is passed an array of Interface
objects which manage the node's communication interfaces. So to run a
servlet you would do:
Interface servletInterface = new ServletInterface(
ListeningAddress lstaddr, // servlet's listening address
String name, // name to use in logs
Constructor cons, // a constructor and its arguments
Object[] args // for getting an instance
);
And include this in the array of Interfaces.
You can see that you can fairly simply write a layer to connect this
to the HTTP servlet API. I encourage you to check out the experimental
branch and comment on the best way to do this.
On Fri, May 04, 2001 at 02:35:30AM -0500, Brandon wrote:
>
> > 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
> Devl at freenetproject.org
> http://lists.freenetproject.org/mailman/listinfo/devl
--
# tavin cole
#
# "The process of scientific discovery is, in effect,
# a continual flight from wonder."
# - Albert Einstein
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl