tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Troy <rt...@ScienceTools.com>
Subject Re: ATTN: TC users _&_ For Gods's Sake Do Something
Date Sun, 11 Nov 2001 03:19:59 GMT

Hi All,

Regarding the suggestion that we gather together a bunch of ready-to-go
downloads, listee Felix <felix@crucial-systems.com> correctly pointed out
that the existing software downloads aren't necessarily "ready to go,"
though I had a good initial experience with both Tc 3.2.3 and 4.0.1. The
real trouble for most of us seems to come after the initial setup when
we're trying to configure for something specific.


I would like to point out that virtually _every_ complaint or suggestion
for improvement that I've heard in this several-thread dialogue can be
completely resolved with better documentation. And I have an idea.


Instead of trying to gather together a plethora of "certified working"
downloads, I propose something we can begin implementing _right_now_ on a
resource we already have at our finger tips - The Forum: We can use it as
a place where we can all easily contribute to specific configuration  (or
other) problem resolution. The idea here is to gather together the
necessary solutions from those among us who have actually solved the
problems. To accomplish this, we create new anchor posts to which
SOLUTIONS _and_not_questions_ are attached. If a person has a problem and
can't find the appropriate topic entry, they create a new one. If a person
finds the topic category but does not find their problem solved under the
appropriate topic heading, when and if they ever solve it, they then go
back to the Forum and contribute their solution to that topic anchor.

This approach has a lot of advantages to what's happening - or not
happening - now. Hopefully these advantages are clear and I don't have to
enumerate them now. ...To illustrate the way, I've posted the first such
topic anchor, "How To Configure JDBC connectivity" - my personal topic of
the day. Perhaps a solution to this was posted yesterday but I haven't
gotten it to work yet. If I do, I'll be SURE to post what I learned under
that topic heading. Each of us has the power to do the same. This makes
each of us responsible for doing our part to contribute to this great
community, and easily empowers us to make a valuable contribution at the
moment we are ready. No muss, no fuss. Just contribute solutions where
people can find them - and they can find them a bit more easily than
digging through a mountain of emails for that needle. (Maybe we should
have these topic-anchors have "ANCHOR"  in the subjec so they're even
easier to find?)

Once again, forum URL: http://nagoya.apache.org:8080/jive/index.jsp

Before signing off, I had a few more thoughts to share regarding these
threads and in particular about Felix's comments. These thought constitute
the remainder of this post - most of which are off topic, and a bit
long...


> > Is exactly the same as the windows version, the vms version ,etc,etc... I
> > thought that was the purpose of java in the first place ;))
>
> business people are supposed to believe this.
> programmers are supposed to know that that is a limited claim at best.
> <snip>
> java is portable...until you get to the real issues like connecting to the
> rest of the machine.

Yes, this is plainly true. But what gets my goat isn't that, it's the
refusal to provide methods to do fundamental things in the name of
running everywhere, forcing each of us to implement our own solutions.
It's insulting. I have had to write C code to do the functions Java just
won't do and I'm quite embarassed to have to do so! ...Still, that said, I
really like Java...


> > If documentation doesn't seem to cover EVERYTHING
> > needed, then the documentation should be updated,
>
> actually i'm more concerned that so much of the documentation covers things
> that aren't needed, are temporary, or are depreciated.

Good point. We need some better "overview" documentation. ... Once I feel
I have a good overview, I'll be GLAD to write one!

> From: "Martin van den Bemt" <martin@isallineed.org>
> Help and fixing issues are done at a very high speed rate on tomcat, I
> wouldn't bet my money on getting this with commercial companies!
> The beautiful way of open source is indeed, as said by Graham, if it
itches,
> scratch it (yourself..)


Neither open-source, nor proprietary solutions are a panacia. We
_need_both._ Those that do not realize this are causing us all grief - and
that includes people in _both_ camps, though you can throw a lot more
stones at Microsoft in particular on this point.


> but another failure of commercial software is that the biz people
> drive the development pace so that too many features get added at the
> cost of stability and purity of concept.


That's just plain wrong. It's all to easy to blame "biz people" whoever
they are. The truth is all the players share in whatever blame there is
for unsuccessful projects. From the technologists side, it's usually that
they either obfuscate their work (often intentionally), or they are
completely unable to communicate at a functional level with anyone who's
not in their peer group. Therefore, the "biz people" don't get the whole
picture and make errant decisions. This is quite typical.


As for purity of concept, lack of it is usually the result of committee
thinking. In a business project context, I'm a STRONG advocate that _one_
person needs to be in charge of and responsible for design. (Responsible
for means that if it doesn't work, they get removed - plain and simple.)
That person then uses a team or committee to figure out what the choices
are and get clued-in on topics that would otherwise blind-side them. It's
very rare for a team any bigger than two to architect a complex project
successfully.


In an open-source context, things work a little differently, but it's
still true that committee and group architecting is very risky. ...Take
for example, a subject near and dear to our hearts: Web-based
applications. Any good software architect could have told you right off
the bat that while HTML is great for static things, it's the COMPLETELY
WRONG MODEL for any kind of interactive application for the simple reason
that it completely lacked _any_ form of context. That's why cookies were
invented and why we now have sessions and so forth - all an attempt to
solve this fundamental problem that was architected wrong from the get-go.
Now we're band-aiding. ...The strongest argument for what happened is that
it jump-started the standards work that will eventually see us through to
a competent strategy with fairly universal interoperability. As it stands
right now, though, if you have a sophisticated application, there's a LOT
to be said for traditional client-server - sans "web". Use the web to get
the customer/user to down-load your app and then they can run it and
connect to your servers directly...


> this is very common in web-shops.  crap code because its all about
> what the manager sees coming out the other end.

Very often it's crap code because they're using a crappy architecture,
have no standards, don't do design-review, and so forth and has _nothing_
to do with the competency of the programmers, per se, and also nothing to
do with the line-manager. It's _usually_ either the architect's fault, or
the upper managers who don't set up their development strategies
competently (tools, code review processes, etc).


> tomcat's config problems have wasted thousands and thousands of
> development dollars/hours that could have been spent fixing the
> problem in the first place.

"Fixing the problem," in my eyes, is _all_ about good documentation.

Well, maybe that's enough stirring of the hornet's nest!

Cheers everybody. Have a good Saturday night - I'm going out dancing!

RT

--
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/



--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message