> I don't quite see how this relates. My objection to the use of the
> servlet in Fred was that it was taking arbitrary TCP streams and
> wrapping them as servlets in order to have the hendled - which _is_
> bloat because java.net.Socket (or Freenet.Connection) object contains
> all the information that a TCP connections provides. Servlets are used
> for HTTP servers, and wrap the application level request, and therefore
> contain a bunch of information methods to describe the application level
> options.
You have a common misconception about the servlet API. It is a standard
API for writing Internet services. Such as HTTP, FTP, finger, echo, etc.. HTTP
Servlets are a second-level abstraction which makes it easy to write Web
services. The proper way for FProxy to be written is as an HTTP Servlet.
It's not. It's written as a servlet. So it has some code which is redudant
since it's provided by the HTTP Servlet API. It should be rewritten to be
an HTTP Servlet. This wasn't done because since the HTTP code was already
written, it was faster to just write it as a plain Servlet. Doing so was
the quickest path to have a product out that people could use.
However, without HTTP Servlets, the plain servlet API was still a useful
choice for programming FProxy and other node plugins. The servlet API is a
standard. It is well documented. Books and tutorials are available. It's
really easy to figure out how to write a TCP/IP service using the Servlet
API. There is no actual pragmatic advantage to rolling your own service
API. It is true that the current batch of services doesn't use 90% of what
the servlet API offers. I have no problem with that. Although FProxy
should undeniably be rewritten to take advantage of the HTTP Servlet API.
> Putting an API for Fred to call Servlets makes no sense because there is
> no reason to be able to plug in arbritrary servlets into Fred, and
> unless you want to turn Fred in a full fledged web server there never
> was.
Actually, the XML-RPC interface is an arbitrary servlet which I plugin in.
It was really great to be able to take some pre-existing code and just
plug it in and have it work. The EOF Freenet Mail SMTP, POP, and NNTP
providers were servlets from another project that I just popped right in.
Even if you were writing code from scratch rather than using pre-existing
code, there is a benefit to using a standard API. New coders can pick it
up quickly.
> OTOH, using servlets internally in fproxy to handle the HTTP requests
> (parsing the HTTP request options into the servlet options) is a
> different matter. If you did that, then the servlet part of fproxy could
> plug into apache and other servers that run serverlets, which might be
> useful - something that, unless I have misread the code gravely, could
> not work today because the internals of fproxy expect to find HTTP
> headers on the stream after the servlet is handled. That is internal to
> fproxy however, such a servlet structure should not be visible to Fred's
> core.
You are completely right that the rest of the servlet API (namely the HTTP
Servlet API) should be integrated and that FProxy should be ported to
that. However, it is also the case that any servlet server which runs
plain servlets can run all of the node plugins. As usual, people confuse
HTTP servlet with plain servlets.
> You are right, you don't. And the truth is that the lower Client
> interface has stayed more or less the same as well, so you could have
> moved it without writing many lines of code even if you had never
> abstracted that.
And if you used SimplifiedClient, you don't have to change any code at
all or even know how the Client interface has changed. That was the point,
to make it so that client writers don't have to care about these things
unless they want to.
> But changes in the interface is not why I want to rewrite the nodes http
> interface for 0.4. I want it rewritten because the current
> implementation has issues. And you can Theo can be defensive about that
> if you like, but the truth is that we have rewritten a ton of my code as
> well, because it too, had issues (this includes the _entire_ application
> level protocol implementation).
I'm not being defensive about the state of the code in FProxy. It could
use some work and it has needed some work for a while now. I'm defending
the interfaces, not the implementation. I stopped working on FProxy when I
was told that the servlet interface won't be in 0.4. I don't mind fixing
bugs, but I won't write code which I know will definitely be thrown away
later. I also won't rewrite my code to use a less abstract interface.
Those interfaces are there specifically so that the code doesn't have to
be rewritten to keep up with interfaces changes.
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
