Dear All,
It's somewhat sad that this discussion has degenerated
into a flamefest, rife with personal attacks and orificial
metaphors.
It's sadder still, Jon, that you quote Paul almost
verbatim in your document "New Project Proposals"
(http://jakarta.apache.org/site/newproject.html) and
put several not-so-obvious-to-a-newbie references
to this thread into the document.
Anyway, let me first clarify that THBS is primarily
a consulting company and intends to remain so. Our
strengths have been in middleware technologies,
especially with J2EE based AppServers. Do take a
look at http://www.thbs.com/ for more information.
In several of our assignments, we face certain
recurring problems (as I'm sure most of you also
do) that are best solved by developing solutions
that solve a class of these problems. These
"scratch-the-itch" solutions, mature over time
to the point where we feel they can be of use
to others.
Take a look at:
http://www.thbs.com/ivalue/ivalue1.html
for more information on some of these.
For example, a real-life WebApp needs much more
than what is offered by an AppServer: a general
WebApp needs to keep track of its users and their
profiles, ensure that only authorised users are
able to access its functions, keep track of its
usage so that it can charge users, etc.
Add to this the fact that as the site grows, you'd
probably want to add more servers for load-balancing
or failovers, introduce new rate-plans for different
kinds of customers - some might be willing to pay
more for a better QoS, modify your user profile
schemata, add more WebApps to your site, be able easily
manage the whole setup through a single point, etc.
This is exactly the class of problems that ASPizer
set out to solve - at the time we started on this,
ASPs were the most visible and greatest beneficiaries
of such a solution. This was certainly the case
for our first customer HumBiz (http://www.humbiz.com/).
We see a trend within large enterprises of moving
their Intranet/MIS applications to the WebApp/J2EE
model, where this solution would be directly applicable.
Thus the name "ASPizer" is somewhat of a misnomer now.
If anyone would like to know how this can directly
benefit WebApp developers, I can send the ASPizer
Programming Guide (48KB/ZIPped-HTML) to them. Or other
documentation for that matter.
Coming to the issues raised in Jon's document and
elsewhere on this thread, I must tell you that this
has been a closed-source project so far with no
external developer community to speak of. It is still
being actively developed and improved upon though, and
as Paul points out, will be for quite some time to
come. We sincerely feel that the J2EE developer community
will definitely benefit from such a solution.
The "itches" that bothered us in our assignments are
certainly those that are faced by most J2EE developers
and sooner or later there will appear appropriate "scratches" -
here or elsewhere. Why not use this as a starting point
rather than starting from scratch? (Unintended pun!)
A case in point being "WebOBlocks" that we developed
around 1.5 years ago for creating reusable WebApp
components based on MVC - there are several
approaches now, even in the OSS world, that are quite
similar to that - dare I say even within the Jakarta
project (Struts/Turbine[partly]/etc.).
No, that was not intended as a ":-P" - I just think
that we as developers should try to get rid of our
NIH afflictions and try to reuse and share as much
of our code as possible - only then can we get out
of the tar-pit that is WebApp development as it is
today.
Wasn't that the whole point of starting the Jakarta
project?
'nuff said.
Sincerely Yours,
Ranjit.
--
Ranjit Mathew E-Mail: [EMAIL PROTECTED]
Member (Technical Staff), Phone: +91-80-209 75 11/12/13
Torry Harris Business Solutions, Fax: +91-80-226 84 42
Bangalore, INDIA. http://www.torryharris.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
