Donald Ball wrote:
[OT, I realize, my last word on the subject]
Ok, then here's my last words on this as well..
I guess I miss-read that preamble. I doubt such a silly license would hold up very well in court ;-)
ofJason's classes aren't free software, they're encumbered by a "buy lots
These days does one really need a lawyer to define *free*. You can download the code and look at it, compile it and distribute it in your project if you’re non-commercial. Obviously there are no restrictions oncopies of my book" license.
building a decent package with similar capabilities if your working on a Commercial project. Besides, if you work for a *Commercial Institution*, I'm sure they'd be glad to buy you one stupid little book so you can meet the licensing requirements. For a private commercial entity, maybe that’s better than having to release all your code to the world to meet the requirements of a GNU license. Really, how *one* decides to package and publish their code is really their business. Nobody said *Open source* was the *only* way you can go when it comes to exposing the code of your software.1. Jason's license requires every member of the development team to own a
copy of the latest version of his book. Expense aside, that's a lot of dead
trees and a very silly license.
2. Free does not necessarily imply GPL. Most of us in the Apache softwareI was just using GPL as an example of a Opensource style license. Note: We use a GPL license on our code, But I think its rather weak to enforce. Plus, I wonder to myself, if anyone has ever been taken to court for violating an Opensource License?
community tend towards BSD-type licenses.
I guess I'd draw the line on what the Servlet API should provide from the HTTP Spec. If the SPEC defines multipart enc type. Then perhapse the Servlet HTTP Api *should* support parsing it. But, I don't have the spec handy so I couldn't tell you.
I agree that if one wants to see a particular change one can get involved. That’s the power of "Community". But, I think its right that this would clutter up an already well-defined "spec". It seems a stable and well organized set of requirements for managing "basic webapplication request/response" transactions. I mean, good packages do "one thing" and do that "one thing" very well.Would you agree that the cookie handling code is cluttering up the spec?
After all, you can manually parse and generate your own cookie header
string.
Conversely, would you agree that the servlet API would beThis is a grey area because GET/POST are methods and mutlipart/form-data is an encoding-type. Supporting the "default" encoding type for a POST probibly makes sense as it is used so much, should the API support other possible encoding tyes as well? Or should it provide the ability to support other encoding types through extensibility mechanisms? (I.E. Wrappers). Simply including wrappers for these features (i.e. something like cos) and alowing one to turn them on and off (filters/web.xml config) is more flexible than enforcing a specific API for the behavior.
incomplete if servlet containers weren't required to parse POST requests
for you? You can manually parse the POST requests yourself, but there is
considerable benefit to be realized by centralizing that code. I think the
same argument applies for parsing multipart/form-data request bodies.
true, but default sessioning is pretty heavily integrated into the Servlet API. In using the API I sometimes wish if didn't "restrict" its functionality the way it does. I.E. I'd like to be able to control the name of my session Id's myself, but the SPEC says they have to be keyed JSESSIONID). I could build or go find an API that allows me to do this. But then my developers would be confused as to which session they are getting, and why can't they just call request.getSession(true); Its a toss up, do I stay stuck in the spec and use the default behavior, or implement it myself. More often than not, I end up wanting to do it myself, so cluttering up the API with what I consider to be poorly designed interfaces creates confusion when the API doesn't give the proper amount of flexibiliy in configuration. All the more reason to let the best models "evolve" in the community and then include the "most used winners" into the API. Granted it might take a little longer than inhouse decision making and implementation. But, the Opensource Community isn't in risk of going bankrupt waiting.diversity that makes for the ultimate flexibility and ultimate interoperability. By not restricting the file upload functionality into an API, it leaves it open for competitive open source development (In reality, I just wish JCP had done the same for the HttpSession API).??? The API just defines an interface which programmers who want to develop
portable applications can use. The implementations of the interface can
compete, proprietary, open source, what have you. And still, people who
don't like the API can develop their own superior API (SAX, anyone?) and
use that. Nothing forces you to use the session API; you're free to write
your own and use it if you like.
Its certainly an interesting avenue to explore. When you give people an opportunity to give their opinion, I think you often get a greater response from those who are opposed.Anyway, I guess I still fail to see why adding support for multipart/form-data requests to the servlet API is controversial, and I encourage people to write the servlet JCP. Back to taglibs now.
-2 more cents
Mark
- donald
--
To unsubscribe, e-mail: <mailto:taglibs-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-user-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:taglibs-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:taglibs-user-help@;jakarta.apache.org>
