Re: Forum Software.

[Jeff Schnitzer]

On Wed, Jan 22, 2003 at 11:15:22PM +, Pier Fumagalli wrote:
> 
> We have a license and an installation of Jive, if someone wants to get it up
> to speed... It's on nagoya.

If you need a volunteer to maintain it, I'll be happy to do so - among
other things, I develop and maintain the Jive-based forums for The Sims
Online.  However, I'm firmly in the mailing-list camp, at least as regards
Apache.  I don't see any reason to "fix" what isn't broken.

IMHO, the forums will be useful to the extent that their purpose does
not overlap with the mailing list and thus split the community.  What
purpose that leaves, I don't know.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Forum Software.

[Jeff Schnitzer]

On Wed, Jan 22, 2003 at 01:08:56PM -0800, Randall J. Parr wrote:
> 
> It seems much of the reason people want to have forums is for the search 
> abilities. There are mail archives available but I must I agree many are 
> so limited in their search abilities and/or interface that they do not 
> help much.

What do you find lacking from http://www.mail-archive.com?  I almost
prefer it to my mailreader.

Jeff

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Sun Is Losing Its Way

[Jeff Schnitzer]

On Fri, Dec 13, 2002 at 06:42:36PM +0200, mohammad nabil wrote:
> 
> support Sun, Open Source, and all good manufacturar in our nice world :)
> 

Do you just not grasp that Sun's rigid control of Java is the
antithesis of Open Source, and _especially_ the Apache philosophy?

Try forking the Java codebase sometime.  See how fast it takes 
Sun's lawyers to find you.  Want to port Java to a new platform?
Get special permission from Sun, and don't plan on having public
CVS (see the FreeBSD experience).

There's nothing "open" about that.

Jeff

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Differences between Structs and Turbine ???

[Jeff Schnitzer]

On Tue, Oct 08, 2002 at 03:03:37PM -0700, Jon Scott Stevens wrote:
> 
> Interestingly enough, I did write a quick little framework that works very
> similar to Turbine and has the same concept of users/roles/permissions. =)

Well, if you want an MVC framework, someone did a port
of Maverick to PHP:   http://amb.sourceforge.net/

:-P

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Database Subproject Discussion : creation of DBCommons ?

[Jeff Schnitzer]

How about tweaking "db" enough so that it both pronounces better and has
less explicit meaning?

I like:  dub.apache.org

Let someone else figure out acronym meaning later :-)

Jeff Schnitzer
[EMAIL PROTECTED]

How many millions of dollars did Andersen spend for the name
"Accenture"? Sounds like some sort of meat seasoning.  No MSG!

> -Original Message-
> From: Jim Seach [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 06, 2002 3:42 PM
> To: Jakarta General List
> Subject: Re: Database Subproject Discussion : creation of DBCommons ?
> 
> I don't have a problem with db, but if that is associated too strongly
> with relational databases, how about datamanagement or dm?  Another
> option would be just data.
> 
> Jim Seach


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: You guys are so funny.

[Jeff Schnitzer]

> >Hear hear!  (But go emacs! ;-)
> 
> B... vi rules!


Ed is the standard text editor.

http://www.gnu.org/fun/jokes/ed.msg.html

:-)

Jeff Schnitzer
[EMAIL PROTECTED]
Yes, I was reading alt.slack in '91 :-)

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: You guys are so funny.

[Jeff Schnitzer]

Sorry, didn't intend to "throw" the whole mail at you.

I haven't been around as long as you (probably a little over a year),
but this is one of my favorite lists.  It's far more entertaining than
television :-)

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, May 04, 2002 10:00 AM
> To: Jakarta General List
> Subject: RE: You guys are so funny.
> 
> Hey Jeff,
> 
> 
> I can agree with all you say but I don't understand why you throw
> this on my direction.
> 
> I have been defending the existence of competing projects since the
> Tomcat 3.3 versus Tomcat 4 wars until my most recent posts at the
> commons-dev list.
> 
> Maybe you do not follow the same lists I do. Maybe not for long
> enough.
> 
> If you read Jon's postings along this thread, you will also be
> better informed about whom has a thin skin problem.
> 
> 
> 
> Have fun,
> Paulo Gaspar
> 
> 
> > -Original Message-
> > From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, May 04, 2002 11:59 AM
> > To: Jakarta General List
> > Subject: RE: You guys are so funny.
> >
> >
> > > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> > >
> > > Of course that from the way Jon talks about me you can tell that
> > > I do not always agree with him - Jon seems to only be friendly
> > > to those that agree with him.
> >
> > For the record, I've even committed the cardinal sin of creating a
MVC
> > webapp framework which is not Turbine (http://mav.sourceforge.net),
and
> > Jon is still pretty friendly to me :-)
> >
> >
> > You guys all need to lighten up.  It's not like this is a workplace
> > where everyone is competing for promotions or something.  How this
> > social game plays out isn't going to affect your paycheck or the
people
> > who hang out with you or whether or not you're going to get laid
this
> > weekend.
> >
> > A fair amount of banter is healthy in any community.  Poking fun at
each
> > other, lighthearted insults, competition, and yes conflict are a
> > standard part of any sitcom production.  Sure, there's a time for
"we
> > all love each other" mushy-type stuff but if it was like that all
the
> > time it would get boring really damn fast.  It is my observation
that
> > Apache works because of thick skins, not because of peace, love, and
> > happiness vibes.
> >
> > There's nothing wrong with a limited number of competing projects
under
> > one roof.  It's probably even a good idea.  It's not like Maven and
> > Centipede are competing implementations of the same API - this is
pretty
> > much a research field, and it's impossible to categorically predict
at
> > this point whether it is better to extend or generate the Gump
> > descriptors, or to use XSLT or DVSL, etc.  Until the science becomes
> > engineering, this mad driving need (among some) to "merge merge
merge"
> > is a pathology.
> >
> > Let it be.  Use the software you like.  Write the software you like.
> > Berate people over the truly important things, like choice of text
> > editor :-)
> >
> > Jeff Schnitzer
> > [EMAIL PROTECTED]
> > ed is the *standard* text editor
> 
> 
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: You guys are so funny.

[Jeff Schnitzer]

> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> 
> Of course that from the way Jon talks about me you can tell that
> I do not always agree with him - Jon seems to only be friendly
> to those that agree with him.

For the record, I've even committed the cardinal sin of creating a MVC
webapp framework which is not Turbine (http://mav.sourceforge.net), and
Jon is still pretty friendly to me :-)


You guys all need to lighten up.  It's not like this is a workplace
where everyone is competing for promotions or something.  How this
social game plays out isn't going to affect your paycheck or the people
who hang out with you or whether or not you're going to get laid this
weekend.

A fair amount of banter is healthy in any community.  Poking fun at each
other, lighthearted insults, competition, and yes conflict are a
standard part of any sitcom production.  Sure, there's a time for "we
all love each other" mushy-type stuff but if it was like that all the
time it would get boring really damn fast.  It is my observation that
Apache works because of thick skins, not because of peace, love, and
happiness vibes.

There's nothing wrong with a limited number of competing projects under
one roof.  It's probably even a good idea.  It's not like Maven and
Centipede are competing implementations of the same API - this is pretty
much a research field, and it's impossible to categorically predict at
this point whether it is better to extend or generate the Gump
descriptors, or to use XSLT or DVSL, etc.  Until the science becomes
engineering, this mad driving need (among some) to "merge merge merge"
is a pathology.

Let it be.  Use the software you like.  Write the software you like.
Berate people over the truly important things, like choice of text
editor :-)

Jeff Schnitzer
[EMAIL PROTECTED]
ed is the *standard* text editor

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: You guys are so funny.

[Jeff Schnitzer]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> 
> I really wonder why it is that all one has to do is say "Microsoft" on
> any Apache thread and they get 100 responses.  I wonder if it works
that
> way on whatever-microsoft-related-lists are out there.

Someone needs to update Ellison's Law, s/Hitler/Microsoft :-)

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: You guys are so funny.

[Jeff Schnitzer]

Dude, do you really need to respond to *every single* piece of mail?

Jeff

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 02, 2002 5:51 PM
> To: Jakarta General List
> Subject: Re: You guys are so funny.
> 
> [part bazillion deleted]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Subproject Proposal - crossdb

[Jeff Schnitzer]

> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> 
> on 4/22/02 12:19 AM, "Leo Simons" <[EMAIL PROTECTED]> wrote:
> 
> > While these may not be accurate summaries, I hope you now do see
that
> > CrossDB and Torque are not, in the majority of use cases,
alternatives
> > to one another.
> 
> I'm sorry. I don't see that. Torque can do everything crossdb can do
and
> more.

Uhhh:  Outer joins?  Fetch data across multiple objects?  Aggregation
queries?

Torque is an O/R mapping framework, with all of the inherent limitations
of trying to make relational data look like objects.  Crossdb is a
database-independent abstraction of SQL (not JDBC, that's an important
distinction!).  

These are not competitive facilities; in fact they should be highly
complementary.  At the moment, Torque's extremely limited Criteria
object has a tough time with simple conditions like "WHERE bob > 5 and
bob < 10".  Subqueries and joins are hopeless.

Crossdb is what Torque desperately needs - a good database-independent
way of specifying sophisticated conditions.  The WhereClause in Crossdb
could be substituted wholesale for Criteria.

And for those of us that have to query our databases and obtain results
which do not map 1-to-1 with a single object (such as anything that
involves a group by or an outer join), we can bypass Torque and still
have database independence.

I think both Torque and Crossdb (if it has the community) are very much
needed as top-level Jakarta projects.  They are both bread-and-butter
server development tools.  Putting Crossdb under Torque makes about as
much sense as putting Torque under Turbine.

Oh, and Jon, the comparison with ECS is not very good.  Web pages are a
creative endeavor, whereas SQL statements are short and built by
hard-core programmers.  Also, simple HTML does not suffer from the
problem of every web browser on the planet requiring a slightly
different syntax for putting columns in a table... Velocity might be
less useful if a separate template had to be written for every single
web browser.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Comments on the commons-logging API

[Jeff Schnitzer]

> From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
> 
> Yes, the defining advantage to the commons-logging API that I see is
that
> it
> allows users to adopt a single logging implementation, which confers
real

What needs to be appended to that statement is "...if everyone codes to
the commons-logging API".  The exact same statement can be reconstructed
using "Log4J API" and it is equally true.

If everyone uses commons-logging, then only one logger must be
configured.  If everyone uses Log4J, then only one logger must be
configured.  If third-party software is using different loggers, then
you have to configure multiple loggers no matter what API your code
uses.

It seems to me that the commons-logging API just adds Yet Another
Logging API... especially when someone gets the bright idea to make a
"native" implementation of the API for performance reasons.

At least with Turbine, Struts, (Maverick :-), etc, there are some
fundamentally different approaches to the problem of how to publish a
web application.  Logging doesn't seem that complicated.  The massive
duplication of this basic feature in the Jakarta codebase is silly, and
trying to build an abstraction layer on top of it seems even sillier.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Micro JakartaOne

[Jeff Schnitzer]

> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> 
> Also, I'm still willing to show people the club, even if we aren't
doing
> anything...

Definitely!
 
Sorry to hear that a big organized shindig won't happen; a small
disorganized shindig would be fine too though :-)  

Jeff
I just started a new contract, so I'm waaay too overloaded to help
organize.  Sorry.  But I'll help contribute to the revelry :-(

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] ASL vs. GPL page: is this okay?

[Jeff Schnitzer]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> 
> The question is: "How do you want to spend your time?"
> 
> Possible answers:
> 
> 1> Fighting an "unwinnable" (defined as the argument having a logical
> conclusion where one side overwhelmingly wins) religious war with the
> GNU hordes (hirds? hurds? ;-) ). . .
> 
> 2> Coding and documenting

There are quite a few people around here who spent an awful lot of time
working on #2 because they weren't successful at #1.  If the WebMacro
folks hadn't stuck to the GPL, it would not have been necessary to
reinvent it as Velocity.

IMHO, evangelizing the APL is an important goal of the Apache project
precisely because it reduces the amount of (re)coding and
(re)documenting we will ultimately have to do.  I applaud Jeff's
document, and I would love to see the finished version linked off the
main Jakarta page (as well as www.apache.org).

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Java is dead... but it could still be saved!

[Jeff Schnitzer]

Those license terms are for the Microsoft "Shared Source" implementation
of .NET, which MS is building on FreeBSD.

The Mono implementation is not based on the Microsoft code and is not
encumbered by their license restrictions.  The runtime is GPL'd, the
classes are covered by the MIT X Consortium license.

You are perfectly free to write commercial applications for Mono without
paying a dime to Microsoft.  You are perfectly free to fork the Mono
codebase if you really want to.  Mono runs on Linux.

I'm definitely going to be looking into it soon.

Jeff Schnitzer
[EMAIL PROTECTED]
(sorry about the duplicate link to J#)

> -Original Message-
> From: Fernandez Martinez, Alejandro
> [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 9:10 AM
> To: 'Jakarta General List'
> Subject: RE: Java is dead... but it could still be saved!
> 
> Hi Stefano,
> 
> > -Mensaje original-
> > De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> [...]
> > My position: give me a solid (possibly GPL-ed) CLI implementation, a
> > Java2C# porting tool, a BSD-licensed library of .NET classes and
> > java-cloning classes and I say let's kiss java good bye.
> 
> And you will be a tinkerer, able to create a non-commercial bare-bones
> application in two seconds. For more, you will have to pay Microsoft.
> 
> "This implementation is intended to meet the needs of academics,
> researchers, curious tinkerers, and those who wish to build
independent
> versions of the proposed ECMA standards."
> 
> Courtesy of Sam Ruby:
>
http://www.microsoft.com/partner/products/microsoftnet/SharedSourceCshar
pC
> LI
> FAQ.asp
> 
> "The Microsoft .NET Framework and its accompanying C# compiler are a
> commercial product, and have features not found in the ECMA working
> drafts."
> [...] "The source code to the .NET Framework will be available under
> Microsoft's Shared Source Licensing Framework-see
> http://www.microsoft.com/sharedsource for more details."
> 
> Is that acceptable for an Apache developer?
> 
> Un saludo,
> 
> Alex.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Java is dead... but it could still be saved!

[Jeff Schnitzer]

> From: Scott Sanders [mailto:[EMAIL PROTECTED]]
> 
> Stefano, you are right on the mark as usual.  As soon as a java2c#
> porting tool is available, the hordes will probably be moving on...

Actually, forget a porting tool.  I want an open-source version of
something like this:

http://msdn.microsoft.com/visualj/jsharp/beta.asp

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [ot] J2EE considered harmful

[Jeff Schnitzer]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> 
> On Fri, 2002-02-01 at 09:19, Alef Arendsen wrote:
> > So what's the score? DotNet is the new Microsoft initiative, and -
as
> always - they've perfectly imitated J2EE and have had a good look at
all
> J2EE's pitfalls. USed J2EE as a basis and extended it in a very very
very
> good way (ok, little bit devil's advocate here). So maybe that's the
next
> thing.
> >
> 
> Yeah, the catch is being tied to their unstable insecure platform.

There is a great quote attributed to Winston Churchill:

Woman to Churchill:  "You're drunk!"
Churchill to Woman:  "And you, madam, are ugly.  But I shall be sober in
the morning."

Unstable and insecure is fixable.  Proprietary is not.  There are
projects like Mono which offer a platform not required to answer to any
single corporation.  You cannot say the same for the J2SE, and vastly
less so the J2EE.

Not that I'm suggesting everyone in Jakarta should drop Java and start
.NET development, but don't harbor illusions about the technology you're
using.  It serves the interests of Sun, not "the community".

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [OT] RE: J2EE considered harmful

[Jeff Schnitzer]

> From: Steve Downey [mailto:[EMAIL PROTECTED]]
> 
> Most objects don't work if they are made distributed without careful
> consideration.

I wonder if that has to be the case.  Right now, our distributed object
containers are blissfully stupid.  We (humans) can point at any
individual class or interface and say "remote thyself!" but that's as
far as it goes.  The container just does what we programmers tell it to.

Just like me, a hypothetical "smart container" could make some pretty
educated guesses about where and when a set of existing objects should
be remoted.  Furthermore, it could automatically learn, over time, not
only where the best boundaries are, but what are the best situations to
perform the remoting/migration.  Instead of deciding which classes
should be remote, a smart container could decide which *objects* should
be remote.  And it could "learn" the answers by watching object behavior
over time.

Of course, architecture would still have a big effect on performance -
but it does already, even in a single-machine environment.  We don't
hand-optimize our assembly anymore, and suspect that eventually we won't
be hand-optimizing our distributed systems, either.
 
JADE and Mobile Agents are not quite what I have in mind.  The "agent"
concept is very thread-centric, whereas this idea is object-centric.  It
sounds like EOB and AltRMI are closer to the mark.  I'm going to have to
take a long look, and maybe try to restart this discussion on one of
their mailing lists :-)

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: J2EE considered harmful

[Jeff Schnitzer]

> From: James Strachan [mailto:[EMAIL PROTECTED]]
> 
> (*) One thing I've noticed with SOAP is that developers from the
different
> camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The
> web/MOM
> guys tend to think of SOAP as a universal message format so the same
> structured message can pass across many transports http/email/news/MOM
to
> connect anything to anything in a language, platform and transport
neutral
> way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its
> CORBA
> but using XML rather than IIOP and go off building stubs/proxies/IDL
> compilers etc just like with EJB/CORBA.

I don't think web/MOM/SOAP and CORBA/EJB are comparable technologies.
The former are communication protocols, and the latter are (primarily)
programming APIs.  To emphasize this point, in the .NET universe, the
remote invocation protocols are pluggable... you can write to their
distributed object model API and use SOAP, DCE-RPC, IIOP, JRMP, SMTP, or
just about anything else you can dream up.  For that matter, there is no
reason why you couldn't create an EJB container which used HTTP/SOAP as
the transport protocol.

I would compare EJB to the programming API for your SOAP or MOM
implementation.  Theoretically EJB (or any distributed object model)
provides a high-level abstraction so you don't need to fuss with the
complexity of all the protocols and mechanisms underneath.  Of course,
the tradeoff is flexibility and performance.  The problem with EJB,
IMHO, is that it has merely replaced the complexity of the underlying
system with the even greater complexity of the EJB system, and still
significantly inhibits your ability to write well-performing
applications.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: J2EE considered harmful

[Jeff Schnitzer]

> From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]]
> 
> Are you just talking about creating a new language, or what?  What is
your
> idea?  I cannot tell.

That's a good question, and ultimately one which would be determined by
the constraints of the technology.  Prototyping would probably involve
using an existing language and platform, and maybe we would ultimately
discover that it is possible to build a system like this on top of a JVM
(or CLR).  My suspicion is that it is not, and may be undesirable for
legal reasons anyways.

The later part of my diatribe was a hastily phrased way of approaching
this subject:

Unless you want to go back to the dark ages of C++, the future is
shaping up to look like a choice between writing for the Sun platform or
the Microsoft platform.  This does not make me comfortable, especially
considering that Sun's approach to Java so far has been *wholly*
anathema to the principals of Open Source.  At least Microsoft has
submitted C# and the CLI to ECMA.  Quoth Jon: *WAKE UP PEOPLE*

I am tantalized by the idea of a third choice:  the Apache platform.  I
propose a discussion of just what that might be.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: J2EE considered harmful

[Jeff Schnitzer]

Amusingly enough, I've been considering writing an article with this
exact same title.  I've implemented two medium-sized systems using EJBs
(http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
been haunting the ejb-interest list for more than a year.  I was never
ecstatic about the technology, but now I'm starting to feel downright
disillusioned with it.

This is not coming from someone stumbling around with the technology.
The first thing I did was read Richard Monson-Haefel's book
cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only
implementation.  I've got most of the 2.0 spec memorized.  I have no
trouble writing the deployment descriptors by hand.

The problem is, even after more than a year of this, I still find that
writing software using EJBs is a steady progress of fighting the
technology to make it do what you want.  It shouldn't be like this.

Having to write three or four different classes, plus an elaborate
deployment descriptor for each object slows things down a bit.  Tools
like xdoclet help, but it's still a complicated and painful process to
refactor anything.

Basic software design patterns are agonizing or impossible to implement.
Observable?  Time to learn JMS and Message-Driven Beans.  Singleton?
Not in the framework... you have to set up an external RMI server.

Presistance in the EJBland is a disappointment.  Even with EJB 2.0,
entity beans are not remotely mature.  There is no support for
relationship attributes or automatically generated primary keys.  The
query language is constrictive, offering no support for ordering,
aggregation functions, or retrieving data which spans more than a single
class.  After 20+ years of research and advancement in RDBMS technology,
this is a colossal step backwards, and the consequence is that entity
beans radically underperform systems with more direct database access.
I find that I must constantly sidestep the container with direct JDBC in
order to meet performance or feature requirements, and it sounds like
this is a common problem.

Overall, my feeling is that Sun tried to cram too many disparate
technologies into a single API.  EJB!  It's a distributed object model,
transaction model, security model, persistence model, component model,
message queue, desert topping, and floor wax all rolled into one!  Some
of it makes sense, but some of it (especially persistence) doesn't.

I'm surprised that people can build large applications with EJB.  My
guess is that it's probably very effective for one particular class of
problem - ecommerce apps.  I'm sure it's no accident that all the
examples in the spec are Order, LineItem, etc.  Unfortunately, this
doesn't help me, or any of the rest of the people who are working on
applications that are actually interesting.  And my guess is that since
ecommerce is 90% of the market for expensive app servers, Sun doesn't
really care.


Ok, enough whining.  What to do about it?  I really like the idea of an
Apache community building a truly free competitor to J2EE.  I don't like
being tied to technologies owned by a single company, so I'm already
pretty nervous by the stranglehold that Sun has on Java and (especially)
J2EE.  But it's not enough to build a marginal improvement over the
existing system, even with Apache's mindshare.  Besides, who wants to
copy a mediocre idea? :-)

I've been giving a lot of thought to distributed object models lately.
I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a
lot of the same.  Since networks are getting so fast these days, I'm
starting to really wonder what it would be like to have a model in
which:

* All objects are inherently remotable.
* Objects transparently migrate for efficiency.

I can think of many interesting, fairly revolutionary consequences of
such a system and I'd love to discuss them.  Ultimately, if such a
system ever made it out of research and into prototype, it could
challenge both Java and .NET, and possibly stave off the coming hegemony
of the Sun/Microsoft duopoly.  (Yeah, yeah, there will always be people
who enjoy working on nonvirtual machines, but they're crazy :-)

Does anyone think some variant of this idea to be worth pursuing?  Or is
everyone wedded to the idea of working on the proprietary Sun platform
known as Java?

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: commentary by Linus Torvalds

[Jeff Schnitzer]

There seems to be some debate about whether or not that is really the
case.  At least it has Richard Monson-Haefel (the author of the O'Reilly
EJB book) and Floyd Marinescu (from TheServerSide.com) confused, from
this post to ejb-interest a couple months ago:
http://www.mail-archive.com/ejb-interest@java.sun.com/msg19000.html

My take:

While section 10.5.2 maked it look like you can leave the PK unset in
ejbCreate and the container will automatically generate a key for you,
the spec doesn't (that I could find) explicitly specify anywhere that
this is in fact the case.  The wording of section 10.5.2 could be
explained by the use of deferred key types, which could conceivably
provide an akward way of making autogenerated PKs, but only in wholly
container-dependent manner.  In the 1.1 spec, it was necessary to set
the PK explicitly in ejbCreate, so some explanation would seem to be in
order... blah.

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Richard Kirby [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 05, 2001 11:54 PM
> To: Jakarta General List
> Subject: RE: commentary by Linus Torvalds
> 
> 
> EJB2 does allow for automatic generation of "freaking primary 
> keys" - unless
> I misunderstood you. Thats one of the points of having ejbCreate and
> ejbPostCreate. Mind you, I personally feel that Torque offers 
> far more than
> EJB, if you are building from scratch and don't have legacy systems.
> 
> Richard
> [EMAIL PROTECTED]
> 
> > -Original Message-
> > From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> > Sent: 06 December 2001 07:28
> > To: Jakarta General List
> > Subject: RE: commentary by Linus Torvalds
> >
> 
> > As a case in point, I would like to point out EJB CMP as an 
> example of
> > "design-driven" technology which may very well look really stupid in
> > another few years, especially given its atrociously slow 
> mutation rate.
> > If anyone who was writing this crap (the spec) was actually 
> *using* it,
> > it would probably allow for automatic generation of freaking primary
> > keys...
> >
> > Jeff Schnitzer
> > [EMAIL PROTECTED]
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: commentary by Linus Torvalds

[Jeff Schnitzer]

And for an example of a dead company whose products are gone too, how
about Ashton-Tate (anyone remember dBase?).

I liked Linus' comments.  They essentially echo the arguments for XP,
that software should be evolved rather than Designed (captial-D).  Even
though he was (apparently) talking about Solaris when critisizing Sun,
the same argument indicts the acolytes of the Java Community Process as
well.

As a case in point, I would like to point out EJB CMP as an example of
"design-driven" technology which may very well look really stupid in
another few years, especially given its atrociously slow mutation rate.
If anyone who was writing this crap (the spec) was actually *using* it,
it would probably allow for automatic generation of freaking primary
keys...

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Neville Burnell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 05, 2001 2:22 PM
> To: 'Jakarta General List'
> Subject: RE: commentary by Linus Torvalds
> 
> 
> their products are still around, still evolving, but those 
> corporations
> are long gone
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 4 December 2001 10:55 AM
> To: Jakarta General List
> Subject: Re: commentary by Linus Torvalds
> 
> 
> Neville Burnell <[EMAIL PROTECTED]> writes:
> 
> > anyone remember Lotus Developments and WordPerfect Corporation ...
> they had
> > billions in the bank too
> 
> 
> Lotus == IBM
> WordPerfect == Corel.
> 
> Still around... just different names :)
> 
> -- 
> Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED] )
>  Location - San Francisco, CA, Cell - 415.595.9965
> Jabber - [EMAIL PROTECTED],  Web - 
> http://relativity.yi.org/
> 
> Yoink dot adios backslash loosers!
> 
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Cross site scripting

[Jeff Schnitzer]

Since CSS vulnerabilities are due to the nature of html presentation, it
seems to me that the presentation layer is clearly the place to fix it.

Storing encoded data is a bad idea, IMHO, because:

You've got to somehow ensure that all input data is channeled through
your encoder.  Sure, this may be easy for web forms, but what about
direct updates or imports to the database?

What happens when you try to use your data in a different presentation
technology such as a Swing or console app?  Trying to de-escape the data
everwhere you use it would suck.

You can escape data for HTML 4.0 and store it... but what about years
from now when HTML 8.0 rolls around and there are new things to escape,
or old things that should be escaped differently?  Reprocess your whole
database?

I think you should always store the data model in as "pure" a form as
possible, and let any particular presentation layer make sure that data
behaves well.  HTML output escaping is pretty computationally trivial,
so performance doesn't seem like much of an issue.  Mixing
presentation-specific encoding into the data model, on the other hand,
is setting up for future peril :-)

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 21, 2001 1:20 PM
> To: Jakarta General List
> Subject: RE: Cross site scripting
> 
> 
> Actually I was busy, what I really wanted to say was that I 
> agree with every
> one of the points you make, but still stick to my prefrence 
> for escaping on
> the way in, but ok lets say only where practical.
> I've been involved myself in a project where we had to accept input of
> script and prepare output of it for display or execution.
> And there are a number of other legitimate uses for some of 
> the techniques
> which come under the umbrella of CSS.
> 
> The only truly compatible answer is to delegate to the 
> application designer
> full responsibility for this task.
> 
> Hence, of course, the requirement for a small API to help 
> her/him do the
> dull hard work. (which I'm right behind)
> 
> d.
> 
> 
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 21, 2001 6:57 PM
> > To: Jakarta General List
> > Subject: RE: Cross site scripting
> >
> >
> > Ok, you're right!
> > d.
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Cross site scripting

[Jeff Schnitzer]

> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> 
>Does anyone have code they want to contribute to get this started? How
are
>you currently dealing with these issues? What is your favorite way to
escape
>things? Do you filter/escape all content or only some content? Etc.

In the world of XSL, I think these issues are already taken care of.  At
least in a "domified" approach, the data only ever gets translated into
XML as a final step, and the XSL processor automatically escapes
anything that will have XML or HTML meaning.

In the world of JSP, I would expect that bean-access custom tags would
do this escaping.  Do the Struts taglibs or any of the jakarta taglibs
take care of this?

In the world of Velocity... is there a switch that can be set on
Velocity to automatically escape anything with XML/HTML meaning?  Should
there be?
 
Of course, all these effectively disable _all_ htmlish tags, which might
not be wholly desirable... still, it seems to me that that the best
approach is to escape everything and then selectively translate *back*
only the tags you want working (like ).

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Business-Oriented XML

[Jeff Schnitzer]

Uhhh, let me tell you what comes and goes much more often than
"platform" languages:  scripting languages.  You're proposing to
exchange a widely understood, highly evolved programming language with a
homebrewed scripting language that has a very high likelihood of
becoming nothing more than a blurb in the jakarta-general list archives
in a few years.  The mere fact that your script has an XML form doesn't
inherently give it staying power; hell, I could pretty easily define an
XML form for Java grammar if I wanted to.

Java is obviously not the endpoint of language design, but it does
happen to be about as good as we have come up with so far.  It's a great
tool for defining business logic because it's flexible, fast (enough),
and very widely understood.  It has sufficient critical mass that it
will be around long after you have gotten tired of working on BOX.  So I
don't buy the argument that BOX buys you longevity - the world of
software is littered with dead scripting languages for dead tools.


The problem I have with the BOX concept is that it is a step *backwards*
from all the progress we have been making towards three-tiered
architectures.  The idea of a new scripting language which abstracts the
writing of business logic in some useful way is not bad.  The idea of
binding it tightly to an HTML publishing framework is *terrible*.  You
talk about how important it is to separate business logic from
presentation, yet you seem to have missed the primary *reason* for this
separation - so that the business layer can live on long after any
particular presentation technology is dead and gone.  The point is that
business logic *can* be reused in a Swing client, or as a SOAP service,
or as part of some sort of XML messaging system, or with the Microsoft
Telepathy Mouse, or whatever else comes along.  Tying your business
logic to HTML or HTTP isn't any better than embedding it in JSP pages.

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Dave Jarvis [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 17, 2001 11:08 AM
> To: Jakarta General List
> Subject: Re: Business-Oriented XML
> 
> Hi, Jeff.
> 
> > I'm with Jon here:  Why the heck would you want to do this?
> 
> See previous reply.  In addition, languages come and go.  Remember
when
> TurboPascal was hot?  QuickBASIC?  C and C++?  Perl?  PHP?  What
happens
> in 5 years when another awesome language makes an appearance and
> everyone forgets Java?  Legacy code, I believe is the term.  COBOL,
> FORTRAN, Smalltalk, etc.  Tying yourself to a language isn't a viable
> long-term strategy.  I love Java, don't get me wrong.  But don't fool
> yourself into thinking it's going to be around forever.  ;-)  (This
> isn't flame bait; I'm using history and nearly 20 years development
> experience as a guide.)  XML, on the other hand, is a technology with
> staying power and a history that extends back into the late 1960s!
> 
> Another reason is that you can write more efficiently in a new
> language.  I've found that BOX source is typically 5 to 30 percent
> smaller than equivalent Java.  It has an extremely tight focus on
basic
> business logic.
> 
> > for defining business logic.  Why?  It's trivial to define such
logic in
> > Java, and doing so avoids the limitations of your script (whatever
they
> > may be).
> 
> The only limits are those imposed by the processing engine's
> implementation language.  (Currently Java, but could be C, C++, Perl,
> etc.)
> 
> Again, coupling yourself to Java (or any language for that matter) is
> not a good thing from a long-term perspective.
> 
> > What if you wanted to use a one-way hash on the passwords?  What if
user
> 
> I had a similar problem already.  The solution:
> 
> 
> 
> So long as "generatePasswordHash" is available to the system (neither
> defined nor imposed), it'll work.
> 
> > information was stored in EJBs or LDAP?  What if you wanted to use
the
> > standard J2EE authentication and role-based security system?  Can
your
> > script handle this?
> 
> This can be solved in either of two ways:
> 
>   1) Set up a small (internal) server that uses an XML-based
protocol
> for
> information exchange.
>   2) Write a wrapper function to extract the information you want
> (e.g.,
> generateHashKey).
> 
> > You can use whatever scheme you would like to test the password,
limited
> > only by your ability to express the behavior in Java.  Furthermore,
it
> 
> 
>   
>   
> 
> 
> As before, not limited to a particular language.  But you might as
well
> use Java, because Java rocks.  :-)
> 
> > this example, the yourHelper object).  How would your system 

RE: Business-Oriented XML

[Jeff Schnitzer]

I'm with Jon here:  Why the heck would you want to do this?

Ok, you've defined a new XML-based scripting language to replace Java
for defining business logic.  Why?  It's trivial to define such logic in
Java, and doing so avoids the limitations of your script (whatever they
may be).

What if you wanted to use a one-way hash on the passwords?  What if user
information was stored in EJBs or LDAP?  What if you wanted to use the
standard J2EE authentication and role-based security system?  Can your
script handle this?

For the functionality you mention, in typical MVC systems (Struts,
Maverick, WebWork, Turbine), all you need to do is define a JavaBean
something like this simplistic example (using Maverick):

class TestPassword extends ControllerBase
{
  protected String pw = "";
  protected String email = "";

  public void setPassword(String pw) { this.pw = pw; }
  public void setEmail(String email) { this.email = email; }

  public String perform()
  {
if (yourHelper.checkPassword(email, pw))
  return "success";
else
  return "error";
  }
}

You can use whatever scheme you would like to test the password, limited
only by your ability to express the behavior in Java.  Furthermore, it
becomes very easy to encapsulate business logic in
presentation-independent facilities like EJBs or standard JavaBeans (in
this example, the yourHelper object).  How would your system reuse
business logic to build a Swing client?

And about the last point you brought up... how is your system any more
platform, language, or database neutral than Struts, Maverick, Turbine,
or WebWork?

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Dave Jarvis [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 17, 2001 1:19 AM
> To: Jakarta General List
> Subject: Re: Business-Oriented XML
> 
> Hi, Jon.
> 
> > Why the heck would you want to do this anyway? You have to be nuts
to
> write
> 
> To begin with, it is a very simple stepping stone for moving old
systems
> that don't scale well (e.g., FoxPro) to one that does.  The system I'm
> working with has hundreds of tables, some with tens of thousands of
> rows, others with over thirty million; not hand-coding the SQL is out
of
> the question.
> 
> > SQL by hand anymore and why would you want to embed it into your
code
> > anyway?
> 
> Embedding the SQL in this fashion creates a tight modular unit that
> performs one piece of the entire site's functionality.  For example,
> consider logging in: a relatively simple task.  The user enters their
> e-mail address and password using an HTML form.  To verify that they
got
> it correct, one would write:
> 
> [File: /logic/Login/main.xml]
> 
> 
> 
> 
>   * FROM USERS WHERE EMAIL=? AND PASSWORD=?
>   
> 
> 
>   
>   
> 
> 
>   http://www.yahoo.com'"/>
> 
> 
> 
> 
> In this fashion, no other part of the system needs to know how the
login
> functionality works.  Also, since the code is interpreted, you can
> change the SQL as required while the system is running.
> 
> How would you write the following functionality:  A web page is
> presented to the user with an HTML FORM composed of two TEXT INPUT
boxes
> (named email and password; with no hidden fields).  They fill in their
> information and now the system must verify it -- simply, easily, and
> quickly.  Please show me a simpler means to perform this task.  Once
> that's done, please make the solution platform, language, and database
> neutral.
> 
> > You guys have totally lost touch with simple concepts like 'MVC'...
> 
> The Database is the Model.
> The Logic is the Controller.
> The XSL is the View.
> 
> I fail to see what I'm missing.  Please enlighten me!
> 
> Sincerely,
> Dave Jarvis
> 
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: How times change !!

[Jeff Schnitzer]

> From: Alex Fernández [mailto:[EMAIL PROTECTED]]
> 
> I wonder: when Microsoft announces things like those, do they 
> even take
> it seriously (since everyone knows they'll cancel it later)? Do they
> hire people? Allocate time for the tasks using Project? Even draw a
> PowerPoint or two to show around?

Actually, I think all of the products mentioned in the article
materialized.  The COM support in the MS JVM was (and still is) really
cool.  The IDE mentioned has several features that NetBeans still lacks
(like syntax checking as-you-type and a startup time shorter than
Ellison's droning speech at J1).  Compared to VB or VC++, J++ was pretty
nice.  It (and the MS JVM) are pretty antiquated these days, but the
products looked like they had a bright future before the Sun lawsuit
pushed them into the development of .NET.

Jeff
- Suddely realizing that he said something polite about MS, and that the
room got very, very quiet :-)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]