Please note that as well as sending this to "servletapi-feedback" I have
also copied it to the servlet-interest mailing list for discussion.
General comments:
I really like the Web Application and Deployment Descriptor concepts, and in
general I feel that the changes are worthwhile. I do however have some
reservations, suggestions and comments on the draft text. I shall list them
in
the order of the text:
Section 5.1, para 3.
"All form data from both the query string and the post body are
aggregated into the request parameter set. The order of this
aggregation is that query string data takes precedence over post body
parameter data."
Although better than previous releases, this is still not fully clear.
What does "takes precendence" actually mean? Consider the following case:
query: a=hello
post: a=goodbye a=world
possible parameter set: a=(hello, goodbye, world)
(ie "takes precedence" means appears first in the list)
possible parameter set: a=(hello, world)
(ie "takes precedence" means overwrites first post argument)
possible parameter set: a=(hello)
(ie "takes precedence" means overwrites all post arguments)
I really hope (and suggest) that my first answer is the correct one,
but it certainly needs clarification in the text.
Section 6.1, para 3:
What does "irregardless" mean? Is it a typo for regardless or
irrelevent of?
Section 6.2
I'm puzzled that there is no "removeHeader". There seems to be no technical
reason (setHeader can have almost similar side-effects), and I can see where
it
might be useful.
Section 7.5
This section needs a good going over. It is grammatically incorrect and thus
very hard to understand.
Section 8.1, para 3.
"This path must be relative to the root of the ServletContext". Should this
really be "ContextPath", as introduced in section 5.4?
This paragraph also ends with the unfinished sentence "If a query string".
It should either finish or be removed.
Section 9.5
I fail to see the benefits of creating yet another "file type" (.war).
It could potentially mean a lot of system admin work setting up a lot
of systems to understand what a ".war" file is, what it's mime type
should be, what if any operations are permissable on it, what its visual
representation should be and so on. What would be the problem with
using a standard "jar" file for this purpose?
Section 10.2
Was there a particular reason for restricting the possibile mappings so
that each web application can have only one extension mapping per extension
type.
My worry is that in a reasonable sized web application it may be that some
common extensions may need to be treated differently in different parts of
the application. Imagine a system which has a servlet mapping to (say
".csv") exported from another application, so it's hard for a single
servlet to determine which type of data it contains, but which may need
different mappings in different circumstances, for example:
/accounts/receivable/*.csv InvoiceServlet
/accounts/payable/*.csv OrderServlet
I can't see any ambiguity in an extended syntax along the lines of:
Any string may have at most one wildcard "*".
A wildcard must either start a string, or follow a "/".
A wildcard may end a string, in which case it refers to all paths which
start with the string up to but not including the "*".
A wildcard may be followed by a dot "." and an extension, in which case
it refers to all paths which start with the string up to but not
including the "*" and which end with the string after the wildcard.
Using the example maps as given, with the addition of a new one
/ugh/*.bop servlet5
/ugh/* servlet6
the incoming paths are all treated the same, but these additional cases:
/ugh/fred.bop servlet5
/ugh/aa/fred.bop servlet5
/ugh/ servlet6
/ugh/index.html servlet6
/ugh/aa/b.html servlet6
Section 11.3
There seem to be three servlet security APIs, not two as mentioned.
Section 11.5.2
I'm puzzled as to why the fields J_USERNAME and J_PASSOWRD must be
labelled in upper case, but the post action j_security_check is in
lower case.
No mention is made of case-insensitivity so I have to assume that
these are case sensitive, but it's wierd, and I'd prefer a
case-insensitive syntax myself.
Section 13.2, "small-icon" and "large-icon"
I strongly disagree with imposing restrictions on the names of the icon
files. First, there is the problem that jpeg files are often also known
by other extensions (".jpeg", ".jpe" etc.), Second, and more important
to my mind, is that IT IS NOT THE JOB OF THIS STANDARD to mandate the
format of names and paths on the local file system.
As a concrete example, I sometimes use systems based on Acorn RiscOS,
which use "." as a path separator and encode file type information
separately in the directory entry.
My suggested solution to this would be to redefine these elements in the
DTD so that the name and mime-type are separate. eg:
<!ELEMENT small-icon (icon-name, mime-type?)>
<!ELEMENT small-icon (icon-name, mime-type?)>
<!ELEMENT icon-name (#PCDATA)>
Section 13.2 "display-name"
The comment for this element seems to have a typo at "short than that"
Section 13.2 "welcome-files"
I feel that the choice of separator scheme for this tag is
short-sighted. Filenames with embedded spaces are very
popular on Windows systems, and filenames with commas crop
up occasionally on Unix and other systems.
At minimum some form of (optional?) quoting is needed, but
why not give each filename its own tag pair?
I hope this has been useful,
Frank.
--
Frank Carver
[ Personal: [EMAIL PROTECTED] http://www.efsol.com/ ]
[ At Work: [EMAIL PROTECTED] tel +44 (0)1473 227371 ]
___________________________________________________________________________
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
