Re: Saving the System i: Fight Rather Than Switch

[Pete Helgren <Pete@xxxxxxxxxx>]

Tom (and Joe),

I can't say I am an expert on the technical aspects of *how* to 
implement System i native GUI.  I guess, based on what you are both 
saying, it is nigh near impossible.  Bummer!

But here is a recasting of the issue:

Imagine, if you will, even though it is very unlikely, that waaaayy back 
in the 70's, or even back in '89 or so when the AS/400 was released, 
that the development environment for 5250 "green screens" was as 
segregated as GUI development is now.  The instructions were:

1.  Run a PC based application to design your UI with language "X".
2.  Deploy it to a "server", so you can see what it looks like and do 
some rudimentary testing.
3.  Write your business logic on the "midrange" box in RPG remembering 
that it is separate but callable from the "server" application. Good 
news! The DB IS integrated!
4.  Debug your application with perhaps three debuggers: One to debug 
the "script" that manipulates some of the client-based code, one that 
debugs the UI server code and one that debugs the business logic.
5.  Deploy the completed application in two or three parts, each running 
in a different "execution" environment.
6.  Hope it all works.
7.  "Rinse and repeat" with the 300 other applications that you are 
developing.

The point is, if development were designed like this in the early days 
of the IBM midrange platform (I am talking about the S34/S36/S38/AS400 
line) it would have never had the success it had.  It would have been 
too hard to develop stable applications.  IBM had the foresight to build 
an integrated development and computing platform that essentially did it 
all: UI, Business Logic, DB I/O.  It was stable, scalable and 
successful.  I think that success was *because* of the integration.  You 
only had to know one language and use a single set of tools.  And, it 
all ran within the same platform.  And, in the DOS application world 
that was rapidly expanding around it, "midrange" applications had a leg 
up on stability and scalability and those applications looked just like 
the DOS applications they were competing with. Except, it wasn't DOS 
(and that was a good thing).

I don't know how that integration was achieved.  Tom, you seem to know 
that and seem to know that it can't be done in the GUI environment.  I 
wonder if someone at IBM said the same about text based, multi-user 
computing in the 60's.  Obviously, whatever the technical challenge was, 
however apparently impossible it might have seemed, they did it.

Yes Joe!  Getting the System i into that space where no one else has had 
success, the integration of a "native" GUI into the OS and development 
environment, is EXACTLY what I am talking about.  Without that, my point 
is that the System i is just another computing platform.  A darn good 
one. A very stable, manageable and scalable one.  But still, in the GUI 
world, *just* another platform.

And, yes, I have programmed Windows apps in C, in C++, in VB, in 
Smalltalk, in Java.  Yep, it is pretty dang difficult to do it right 
(easier in some languages than others). But that is in an environment 
where you may need to consider deploying the resulting application to 
multiple OS's and multiple versions within OS's.  Seems to me that IBM 
could have gotten GUI applications right for development and deployment 
on the System i */exclusively./* That is what they did with 5250 
applications and it worked very well (better than DOS but looked *just* 
like it!). Doing the same with a GUI seems like a way to leverage those 
same System i benefits and assets in the same way a text UI worked in 
the past.

However, if there are technical reasons as to why that can't be done, 
well, that certainly explains why IBM is in the pickle it is in in the 
current GUI world. It's tough to differentiate yourself from the rest of 
the pack when your product just serves resulting similar applications, 
even if it does the serving better.

I am suggesting a way to *improve* the prospects of the System i.  I am 
not bashing it nor am I naive enough to believe that fixing the problem 
is easy. I love this box.  The opposite of love is indifference and I am 
NOT indifferent. But, imagine that developing a GUI application was 
similar to developing a 5250 application in terms of integration with 
the System i environment.  That would an improvement. That would be a 
competitive advantage. I'll leave the technical details to those that 
know the hardware, however impossible it might seem.

Pete



Tom Liotta wrote:
> Pete Helgren wrote:
>
>   
> > Since IBM did such a GREAT job on integrating all these things as you 
> > have well outlined, why did they NOT integrate the GUI ?
> >     
>
> I have no idea what this means. How do you 'integrate the GUI' on 
> any large multi-user system?
>
> I mean, do you add a GPU each time you add a user? Or buy a new 
> monitor/keyboard/mouse to plug into a kind of "brick" with an 
> Ethernet port leading back to the System i, like a net-station? Or 
> the 5292 graphics workstation? Or X-windows? Or Java RAWT (NAWT, 
> whatever) which was actually available almost from the beginning but 
> who out there clamoring for GUI ever worked through using it? Or use 
> any browser (which hardly seems "integrated")?
>
> Or do we mean that i5/OS should somehow automatically manipulate 
> Windows GUI elements? Linux desktop GUI elements? Or GUI elements on 
> any new desktop OS that gets released next month?
>
> I suspect that there's isn't anything resembling a clearly 
> understood and widely accepted definition of what "integrate the 
> GUI" means. How about starting with some basic requirements?
>
> Tom Liotta
>
>