RE: 520 pricing structure

Brad, you've stopped even being meaningful.

> We're not talking about that... and no, it's not
> impossible.  

(...)

> Templates make it 10000x times easier, though.

If templates are 10000x easier, then without templates is impossible.
You're splitting hairs.


> IBM went from bad to worse when the changed the net.data
> (which still exists in their apps) to Java...

Opinions, no facts other than that you don't like Java.


> As I said before, I was.  All my apps did was iterate
> through a loop x times, replacing a variable in the
> template with the value of the counter.

Huh?  All of that time, then, was overhead Brad.  JSP pages don't need
to ever do any of that.


> One job handles every request...  the web server never
> starts another one?  Ever?

Nope.


> > > You first say they're close in performance (JSPs being
> > a
> > > little behind), then that a servlet (I thought we were
> > > talking JSPs) will outperform...
> >
> > Again, I'm taken aback at how little you know about the
> > topic.  JSPs ARE
> > servlets, Brad.  A JSP is converted into a servlet.  The
> > servlet is
> > compiled into bytecode.  Finally, the bytecode is
> > compiled into native
> > code by the JIT compiler.
> 
> I do know that....  But that's like saying ICE is water and
> we were talking about ice.

No it isn't.  I was talking about JSPs, which are implemented as
servlets.


> Thanks for explaining that though.. I can see how there
> would be no overhead in all that work.  :)

Your sarcasm really shows how little you know, Brad.  The conversion of
JSP to servlet and then to bytecodes happens only once, and only during
installation in production.  The conversion of bytecodes to machine
code, also known as JIT compiling, happens once during a server instance
run.  The immense performance benefits of this approach have been
documented pretty carefully.


> I don't need a DMZ if my routing is set up properly.  RPg
> CGI  has NOTHING to do with being able to be place
> something in a DMZ or not.

Either your iSeries is open to public requests or it isn't.  If it is,
then it is in the DMZ; that is, at least one port is accessible through
the firewall.  With a separate UI box, ZERO ports are available to the
outside world.

If you don't understand the implications of that, then there's little I
can do to explain it.


> I've worked with very large companies for years and I've
> seen the biggest server farms get crippled by something an
> smaller iSeries could handle without skipping a beat.  A
> single $500 PC will handle decent volume, but start adding
> DB access to that and it quickly drops.

You really aren't staying on topic very well.  A UI machine requires no
DB access, except for loading the application code and the static data.


> > It proves that if I use CGIDEV2, I have to learn
> > something different to
> > use e-RPG, and something yet again different to use Bob's
> > package.  And,
> > unlike JSP and Java, none of them are being taught in any
> > school on the
> > planet.
> 
> No, because any programmer worth their weight should
> understand what it takes to do what they want, and finding
> the correct procedure should be child's play.  The same way
> they should be able to move from language to language.

HUH?  Programmers should intuitively understand RPG-CGI?  But JSP is too
hard?  You're slipping into the Bizarro world, Brad.


> If someone doesn't understand Cgi, HTML, Javascript, SSIs,
> etc.. they'll have just as much trouble with JSPs.
>  Probably more.

Actually, they don't because of the division of labor.  They simply
write the business logic which doesn't give a whit about the JSP, other
than the basic names of the data fields being sent.  Then they turn it
over to a JSP designer, who basically applies all the pretty JavaScript
and so on to the JSP page, since after all JSP is little more than HTML.
It's usually a much cleaner divide than any RPG-CGI template language.


> Either or...  if you are an RPGer, then you are included in
> We... don't assume I was leaving you out.. you have
> mentioned many times how you value RPG lately...  I'm just
> defending it all the way, even for web interfaces.  Which
> doesn't mean that I think it's the only way.

But it's a BAD way to do web interfaces.  Just plain bad.  The same way
that SQL is bad for doing single-record access, or that assembly
language is bad for writing business applications.


> Again... it's the vehicle to present web pages we're
> talking about here...  I don't feel the need to complicate
> things with JSPs.  You feel it's not a complication.  We'll
> never agree, you'll always try and dumb RPG CGI down but in
> the end, we all create nice HTML web pages that to "us" are
> easy to create and maintain.

But the architectural problems, from scalability to the inability to
move the UI off of the primary server, make it so it's not just an
either/or decision.  RPG-CGI has specific, irreparable limitations, and
any business decision to use it must be able to point to other benefits
that outweigh those negatives.


> And I feel the opposite.  I'd say more shops benifit from
> RPG-CGI than not simply because it's their knowledge base.
>  It's in NO means a dead end.. if anything it's a stepping
> stone should a team choose to move to a different
> architecture.

This isn't a "feeling".  RPG-CGI is architecturally stagnant, and using
it causes companies to delay their movement into Java and thus lose all
of the other benefits that Java brings to their IT department.


> Who you should be fighting is IBM and the websfear guys who
> are giving Java a bad name... LOL!

To my mind it's people like you who give Java a bad name.  You don't
understand it, and so you fear it, thus the cutesy "websfear" moniker.

Joe