Re: Tag for uploading

[Mark R. Diggory]

Sorry, I just got to get in on this!

Stefan wrote:

Well I know one thing for sure, uploading files is standard 'out of the box'
with ASP.net. That is one thing that makes me scratch my head about the Java
platform, there are many common things that are used constantly in web
programming that are not directly addressed in a reasonable manner:

Uploading files
Simple implementation of JavaMail (I used Java mail as is but a facade
should have been put in place on top of it.)
Paging of collections
Rich Calendar
Client and server side validations
Auto-formatting of collections on the page.
Keeping state of form widgets

etc...

I know some if not all are being addressed in various places, I just would
have thought that SUN and the JCP would have had this stuff out already as
part of the core features of Java. Now we have to run all over the place to
put stuff together ...

This is especially interesting when all this is addressed in the competition
(.NET) for well over a year (Beta 2 had all this and Beta 2 is pretty
representative of the final release.)

I think that’s because we Java Programmers like to *know* the code of the packages we are working with and not rely on some proprietary *black box* that Microsloth is trying to *shove in our face*.

Just my two cents.

Stef

----- Original Message -----
From: "Donald Ball" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 07, 2002 10:27 AM
Subject: Re: Tag for uploading

It's been discussed to add it to the Servlet spec a few times, but it
gets shut down every time because it's not obvious how it should look
like to handle all possible requirements and still be easier to use
than one of the existing "third-party solutions" (like Jason's filter
and parsing classes). For instance, how to deal with large files (reject
them or store them in a file?), how to get access to regular parameters,
how to get access to the files (InputStream or File?), how to set
limits, download directory, etc, etc.

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.

It's not impossible to come up with answers to all of these questions,
but so far the opinion of the spec group has been that existing
third-party solutions are sufficient and that very little would be
gained by adding it to the spec (in fact, it would make the spec more
complex, and arguable file upload is not in scope for the servlet spec).

Nothing but the ability to code java webapps that handle file uploads in an implementation-independent fashion.

If you feel strongly about it, I suggest you send it as a suggestion
to the spec group.

I strongly encourage people to do so. This situation won't change unless
many people write in and complain.

- donald

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.

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

my 3 cents
Mark




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