× 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.



Hey Bob!

I live in the US - lexicon invention is part of the deal!!

While your points are valid, they do not seem to apply to the majority of
the server-based tools on the market. You may be taking a new approach, but
the majority of currently available server-based refacing tools simply
intrude on the code or the data stream, take the same green screen data that
was originally being sent in a 5250 format, and redisplay it in an HTML
format. The original application still operates in the manner in which it
was designed - it thinks it is having a conversation with a terminal.

Using a simplified OSI model for example (where there are a presentation
layer, application layer and database layer for the development model) most
refacing tools simply integrate to the presentation layer. Without
reengineering the original application to remove the presentation layer -
for example, let's re-write all our interactive RPG withOUT a display file -
we are still screen scraping the original display file screen conversation.

I assert that the diversion of the data stream at an earlier point than a
telnet connection is still screen scraping.

If we continue to think that our legacy applications are pigs, then we will
continue to need lipstick, plastic surgery and beyond. When our legacy
applications are rewritten so the presentation layer is separate from the
application layer and the database layer, then a server-based presentation
layer will be a powerful tool. Until that industry wide reengineering takes
place, the lexicon of the 80s will remain in the marketing vernacular - pig,
lipstick, screen scraping, etc. and screen scraping will survive.

Bob, you were the one who encouraged me to write modular code in 1983 on
S/38. It took me some time to understand, but all my applications were built
modular from that moment. One exception  (which rears its head in this
moment) has always been a display file - an INTEGRAL part of iSeries coding
techniques. I would love to see a hand-written iSeries application that
utilizes display file server programs, but alas, they are simply toys for
some of us uber-techies - mostly pigs with wings. Application development on
the iSeries does not have the modular structure to allow us to truly
separate the presentation layer with a server. Without radical application
reengineering, the concept of a set of characters in row 2, column 3 (3 or 4
long) is inherent to our development environment, platform and even our
psyche.

Until that day, we have a data stream to deal with. Screen scraping
pervades.

I say, give that pig some wings - and at least let it ~look~ like it is
flying!

Trevor


----- Original Message ----- 
From: "Bob Moore"
Subject: RE: webfacing and competing products


> Trevor,
>
> Screen-scrapers
>
> To integrate with host applications from non-standard client systems,
> developers commonly use text -
> filtering systems that process the screen-by-screen results of terminal
> interaction. These systems are
> generally called screen-scrapers because they have to extract meaningful
> data from a screen's worth of
> undifferentiated information an inefficient method at best.
> Screen-scraper interfaces are some of the least
> robust interfaces possible because of the many assumptions that have to
> be made when determining what
> data from each screen is important. Very little can be done to catch
> errors or provide for unusual
> situations with a screen-scraper because the interface definition is so
> arbitrary. If the third through fifth
> characters of the second line of the fourth screen are used to indicate
> the three-digit product code of a
> widget, for instance, the entire interface could be thrown off by having
> four-digit product codes come into
> use after the interface is developed. Processing application data post
> client receipt on-the-glass is too
> little too late. The light weight screen-scraper approach does not allow
> server based transformation where
> application interfaces and system data are current, available and known.
>
> Familiar? Pigs cannot as far as I know fly, new lipstick look or no!
>
> Inventing one's own lexicon does not alter reality!
>
> Bob Moore


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.