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

Reply via email to