× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



There are a few, very few applications for which it is better to run locally. I don't have a "crystall ball" but it seems that web is taking over and with time passing you will have fewer...

Now respect to your points:
1- MS has resources, but its goal is to lock users into windows, not to free them to use other OS.

2- Typicall business application (display account, balances, etc. record purchases, paymentes, etc.) uses JavaScript to improve usability, not as a critical part. My experience is that pages in web take between 50 and 300 miliseconds, not 3 secconds. It is true that a 10 green screen program will translate to 10 web programs, but also 10 green screens will take much more than a second.

3- Neither says "al green screen shoud be replaced by fat clients"

4- Fully agree, there is a very small group of applications that still work better in a fat client, most application will work better in web.

5- In case you work with people who only know windows, web looks very complicated, slow, etc.

Mark Villa wrote:

1st) I think most folks have seen Microsoft Outlook's thick and thin
client that communicates with the server. Assuming you are using the
MS IE browser there is only one vendor involved.

Point: with endless resources and years of tuning the web interface
pales in functionality, usability and speed/efficiency compared to the
windows native interface.

2nd) I do not understand the argument and conviction that all mission
critical iSeries apps should be web based? "you" must be using a
different Internet than what I see. Even if all business objects are
on the server side instead of Javascript complexities and your pages
are flawless, you will need about 10 web pages to replace a complex
5250 screen.
10 * 3 seconds = 30 seconds + validation and population I/O's. The
stateless programming paradigm is radically different than the windows
event driven model.

A web driven application is slower any way you slice it - and these
are under the best circumstances. The gmail interface I am using now
is deficient compared to native WIN of 10 years ago.
on the other hand - WEB has a zero deployment and I can save a draft
and finish in the kiosk at the airport.
Point: each deployment has it's place. Not everyone can seriously
consider "web deployment" as a viable target platform.

3rd) I doubt you will see anything here:
http://www-03.ibm.com/systems/i/roadmap/
that says: To preserve sanity, all green screens are being replaced by
browser based screen methodologies.

Point: I would start with the roadmap and consider all vendors that
fit your business requirements. There are solutions that you will not
outgrow that help us make our companies more competitive. Just
yesterday, it took 4 people at three different workstations and about
25 minutes of my time to change my air ticket and actually assign a
seat. I kept hearing them talk about codes like "2J" and "all 15 codes
must match" before you hit enter. This is pathetic and the opposite of
what we all want the customer to experience.

4th) I hope that we qualify some of our "excellent experiences" with
the fact that target code generation is within the confines of an
optimized tool set or paradigm. In other words, some tools are
designed for a limited set of OPTIMIZED solutions - and that is OK.
But it is not for everyone and a subset of where we should be going.
If I understand the proponents of the C# flavor, it sounds a lot like
you are shifting the business logic to the client. It belongs on the
server.

Point: how many skill sets are needed to rebuild your mission critical
applications.

5th) although I (and many) can list many more top 10 reasons to do
this or that. We could (with a little effort) reach a consensus that a
WYSIWYG just in time deployment of Windows or Linux native
applications that fit with the "state of the platform art" and all of
our business rules, logic, triggers, etc are on the server(s) might be
the best replacement method for the 5250 screen. Living with what is
practical is what we do.

Point: This is why deploying windows native is still a valid choice
for internal users. Those that seek out just-in-time deployment
services spend fewer Saturdays at work.
---End




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.