On Fri, May 04, 2001 at 02:35:30AM -0500, Brandon wrote:
<>
> > 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.
But then you need to load the Servlet AFTER the connection has been
handled by an HTTP server. With the current structure, where we are just
throwing the plugins the raw streams, there is no way those methods can be
implemented. Beside the three things that Tavin wanted to pass in his
messsage, the only other thing we know about the connection is the IP it
came from - everything else requires some protocol layer between the
socket and the servlet (very obviously intended to be http).
If you are going to be doing that complicated HTTP things, you are much
better off turning things around and contacting the Freenet node from a
script or servlet in the http server anyways.
> > 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.
Implementing an Interface (with a single method) is NOT learning "another
Freenet-specific architecture". If a java programmer can't read and
implement an interface, they are in trouble anyways - it is silly to try
to use misplaced and bloated ones so that they won't have to. The reason
why we would use the standard the servlet structure would be so that
plugins from other servers could be used, and we can't (and have little or
no reason to) do that anyways.
<>
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
[EMAIL PROTECTED]
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
