RE: OpenSource version of WebFacing (was: alternative to WebFacing) -- MIDRANGE-L

Nathan,

I added a few comments (>>)

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of Nathan M. Andelin
Sent: Wednesday, June 27, 2001 12:56 PM
To: MIDRANGE-L@midrange.com
Subject: Re: alternative to WebFacing


If something like Webfacing is home plate, then my ideas of Web applications
are far out in left field.

>> I, personally, don't know that Webfacing is home plate, or that your
ideas of Web applications are out in left field, either one.

On the other hand, I don't want to discourage an
open source project.

>> I know that, for sure, having read your post on the News/400 discussion
forum on Leslie's article.

The folks who saw the opportunity to provide tools to convert legacy
applications were way ahead of me.  Actually, the resulting applications
were far from my architectural ideal, so I steered clear of that
opportunity.

My priority is to NOT fetter the browser or any other Web client with the
constraints of DDS.  I believe the differences between Web clients and 5250
terminals will become even larger over time.  The programs that service Web
clients eventually need to offer greater flexibility and  independence than
that offered by the 5250 architecture.

>> ICBW, but I don't think there's much disagreement over what you're saying
here.

The question is when to bite the bullet and build-in the necessary degree of
separation between client and server.  My belief is that the need is sooner
rather than later.

>> I think this is where the question lies.  I've always been strong on the
concept of iterative approaches to changing things.  Especially something as
complicated as the man/computer interface.  This problem is no less
complicated than that:  changing how users of iSeries computers (which also
includes programmers) interface with the computer.

Actually the architectural ideal I try to adhere to is
to also separate server based business rules and DB I/O from server based UI
control.  In my opinion, that's the right level of modularity for
long-lasting, maintainable applications.

>> I'm not telling you anything to suggest that this is going to be hotly
debated.  Everyone is going to be in favor of "the right level of modularity
for long-lasting, maintainable applications" but everyone from PhD's down to
entry-level coders seems to have a different idea of how to get there.

So, while others are making money or building solutions from transition
technologies like Webfacing, I want to cut a course that supports the
Model-View-Controller architecture.

>> I haven't studied enough of Phil Coulthard's articles over on IGNITe.
What little I've seen seems to be very, very solid.  Of course, he's
obviously going to pump the Webfacing approach to getting there.



>> I'm going to throw a little wrench in this discussion, but I think it's
important to stress that the very best technology has limited value if it
doesn't get into wide-spread use.  I'll make an example of the RPG compiler.
The improvements to the language have obviously been huge, yet a large
percentage of programmers are not even using ILE, let alone the advanced
features available.  So how do you judge whether the RPG compiler is
successful.  The compiler is wonderful technology, but at the same time it
is a business system.  Business systems are generally judged by sales, and
if you eliminate sales that turn into shelfware, ultimately judged by usage.
Because the ILE compiler is bundled with the RPGIV compiler, this is hard to
judge accurately.  The numbers of heard, considering how long ILE has been
out, are pretty dismal.

>> (Now I don't want to leave the impression that I don't think the ILE
developers didn't have an adequate transition strategy.  IMHO, it had a lot
more to do with circumstances; namely that Java was being pushed very hard,
from all corners, right at the time programmers should have been looking at
the new features of ILE.  So now you have the situation where programmers
that haven't yet taken the plunge are going to be looking at V5 free-form
RPG, and they're going to have a tough time.)

>> I think this example shows that, no matter what solution, and no matter
how elegant, if the jump is too big for programmers to make, there is little
chance that solution will be widely used.  Look at the uphill battle the ILE
developers have faced, and they've got the full backing of IBM, and the
leaders in the programming community, behind them.

>> I see what you say about the downside to transition technologies, and I
don't mean to minimize it.  And I can't even begin to comment, in any
detail, without knowing more of the particulars about the various
alternatives you all have.  But I can say that, unless you have a way for
programmers to take incremental steps to learning how to use the
solution(s), neither they nor the end-users will get the full benefit of the
solution.



>> ***But here's the thing:***  You favor an approach, Joe favors a
different approach, and I'd probably favor a third and fourth different
approach.  And I'll also go out on a limb and say that Brad is going to
favor the approach of e-RPG.  Just a wild-hair guess...;-)

>> I think this points to what Joe said about the problems of starting OSS
development of this, or really any, project.

>> And while there's certainly a lot of benefit to discussing the pros and
cons of the various alternatives, and it's absolutely necessary, that
discussion doesn't tend to bring people closer to doing any OSS.  It tends
to highlight the areas of disagreement.

>> You may have seen the post to Joe and Brad, where I said I'd try to lay
out one or more possible ways to organize an OSS project, in an IMHO column.
I plan to float some ideas on the subject, starting with a reply to Joe's
previous post (hopefully sometime today).  That's why I'm going to try to
steer clear of discussing the technical merits of one approach over another.

>> But I do want to point out, here, that pursuing your individual approach
and pursuing a common OSS approach is not mutually exclusive, at all.  If an
OSS project like this gets of the ground (big if) and if you decide to
contribute, you'd obviously have less time to devote to coding your
particular favorite approach.  But I'd imagine the experience you gained
working together with others on the OSS project would help offset the loss
of your time.

>> Also, if enough people volunteered to work on the OSS project, there's
nothing to say that the OSS team couldn't tackle multiple approaches.  In
fact, there's a lot to be said in favor of doing this; but those are design
decisions.



Thanks for your thoughts, Nathan.  I hope you'll also contribute on the
subject of how something like this should be organized.

jt

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---