>>> Julien Gilli <[EMAIL PROTECTED]> 30-Jan-01 8:43:05 PM >>>
>Ths is very interesting and, to me, would be one
>of the most original part of the Servlet technology.
>However, i haven't seen any of these possibilities
>in the real world. So my questions are : Have you
>seen it ? Are there plans to do it (beta server,
>beginning of support somewhere) ? Is it at least
>possible ?
If you look on the archives you'll see that there has been quite a
lot of discussion on this (but you have to go back to the very early
days).
Answers to your questions:
Yes it's possible.
Apache James is a servlet implementation of SMTP so that servlets can
do mail filtering.
No there aren't plans to do it (from any major vendor AFAIK).
>This could lead to extends the functionalities of a
>FTP server for example. Thanks for your help in
>advance.
After many of us early adopters had tried building other protocol
implementations of servlet engines we discovered that servlets weren't
that usefull at doing session based protocols.
Since most other protocols are session based this is why not many
have been tried. Apache's SMTP implementation is the exception.
There are 2 ways to implement another protocol:
1. provide a protocolServletRequest and protocolServletResponse
which are used to call a single protocolServlet.service() method. The
method code must establish what the command to process is and what to
do.
There must also be a state carrying element to the request/response
since most commands in most protocols have state, eg: the RCPT command
in SMTP must be issued after the FROM: command; the CD command in FTP
changes the directory, etc....
It's quite complicated to write methods like this... if you've ever
tried to have a single servlet handle state across multiple
invocations you'll know what I mean.
2. provide a protocolServlet with command methods
the command methods get called with a light weight request/response.
This is slightly better but for complex protocols you end up having
to implement an awfull lot of methods.
Also the request/response end up not being that lightweight.
You're also still stuck with the state question.
eg an FTP servlet:
public class MyFTPServ
extends FTPServlet
{
public void cd(FTPServletRequest req,FTPServletResponse resp)
{
req.setCurrentDirectory(req.getCDArgument());
}
}
Extrapolate from that.
Lastly why would you want a servlet engine dealing with another
protocol? HTTP is pretty much the standard for information retrieval
now... sure specialist needs require other protocols but those
specialist needs don't need scripting.
For example, the only reason to use FTP these days is for large file
transfers (because it's more efficient). But when are you going to
need to generate a large file transfer on the fly?
Nic
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
