tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Donald Ball" <db...@rhoworld.com>
Subject Re: Tag for uploading
Date Thu, 07 Nov 2002 18:06:59 GMT
[OT, I realize, my last word on the subject]

>>>Jason's classes aren't free software, they're encumbered by a "buy lots
>of
>>>copies of my book" license.
>>>    
>>>
>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 on

>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 software
community tend towards BSD-type licenses.

>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 be
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.

>Plus, its sounds like you are trying to change a standard because 
>everything you wanted wasn't "spoon fed" to you, or because you don't 
>want to get off your butt and learn to tie together a set of already 
>existing, community developed, tools that each do their job very well. 
>Isn't this that "Community Process" that Microsloth CEO Steve Balmer was 
>ranting was the "Open Source Enemy" several months ago, and then turned 
>on his coat tails and started crying, "We need to embrace the 
>Community!" The whole point of community is that no *one* entity has the 
>monopoly on the code! No one entity defines all the standards! Itís this

>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.

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.

- donald


--
To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>


Mime
View raw message