|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
