On Fri, Jun 22, 2001 at 02:44:16AM -0500, Brandon wrote:
>
> > 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.
This is clearly not the case. As Tavin points out the ServletRequest
interface:
http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletRequest.html
Defines a number of methods that make no sense what so ever if intended
for wrapping a raw Transport layer socket. ServletRequest methods like
getContentType(), getCharacterEncoding(), getProtocol() etc only make
sense if it represents an application layer, or at least an presentation
level protocol.
HttpServlets are an implementation of this for when the the application
level protocol is HTTP.
In fact, the more I think about it, the more sense the Servlet API
makes, and the less sense the way fproxy uses it does. The
ServletRequest/ServletResponse objects are the equivalents of our
RawMessage objects, and the break down the presentation layer for the
application level code to deal with. In such a context, I can see the
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.
My point is that people should not have read a book or study an API to
write Freenet plugins at all. They should be able to do so from a single
method - that is absolutely all that is necessary for what you are
currently providing.
> > 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.
And these use the FreenetServletRequest objects?
<>
> > 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.
Yes, I know. But I prefer quality to quantity, and "caring about
these things" makes better clients.
<>
> 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.
I can appreciate your use of the Servlets for the EOF services (as long
as you are, as I believe, using ServletRequest/ServletResponse objects
written for each specific protocol). However, the best way to call
servlets from Fred would be to simply write an implementation of Tavin's
one method interface that calls them, that way it can be kept out of
Core and Node objects, and people that do not want to use servlets don't
have to load that code at all.
--
'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
