Re: webfacing and competing products -- MIDRANGE-L

Bob,

I had to read this a couple of times, because I was confused. Now I get it.

You and I seem to agree in principle that the way most CURRENT refacing
tools work is to "screen scrape". This was my original assertion, and your
replies seem to agree.

So, the next step is, what else are we discussing? That was the confusing
part. I delved, and found that you are talking about how you think it
~should~ be done. Since the discussion was originally about ~current~
refacing approaches, I will stick to that and let you continue with your
"how it should be done" theories.

Funny thing is, the propaganda machine is now working out of Australia..

Trevor

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


> Trevor,
>
> >
> > I live in the US - lexicon invention is part of the deal!!
> >
>
> Not only do you guys mess with definitions but also pronunciation
> and spelling. Lexical invention could be interpreted in this
> context as propaganda?
>
> > 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.
>
> I am not referring to how it is currently done by others, rather
> how it could/should be done while protecting the investment and
> skills embodied in most application systems on an iSeries. Intrusion
> introduces duality of being for any application, pre and post
> conversion. Dilemmas and bear traps abound here in an expensive,
> complex neo tech landscape. Most times I see over engineered
> solutions being used as leverage for training and service revenue
> intrinsically bound to user pays client based licensing regimes.
> You have assertions and assumptions here that have been introduced
> by vendor attempts focused on conversions not transitions.
> Existing applications do indeed use 5250 protocol but are not
> limited by it. Even today's display files can do lots more than
> just  character based interaction, vendors just do not support
> full scope available.
>
> > 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.
>
> The concepts underlying the three layers that are at the heart
> of Open Systems Interconnect (OSI), the Transport Layer, the
> Session  Layer, and the Presentation Layer do not tally with
> your assertion? The MVC paradigm is a way of breaking an
> application, or even  just a piece of an application's interface,
> into three parts: the model, the view, and the controller.
> MVC was originally developed  to map the traditional input,
> processing, output roles into the GUI realm:
>
> Input --> Processing --> Output
> Controller --> Model --> View
>
> Your lexicon again! you are misinterpreting differing concepts.
> Limiting the conversation to 5250 only? this is not necessarily
> the case. Major motivation to rewrite is to avoid CPW limitations,
> this can be done without touching your applications or sacrificing
> any function.
>
> > I assert that the diversion of the data stream at an earlier
> > point than a telnet connection is still screen scraping.
>
> Telnet? who mentioned Telnet? Host access is not restricted to
> an ageing, static and rigid RFC manifesto of interaction these
> days.  By your definition SNA sessions over IP are screen-scraping.
> You miss a fundamental point I think, instead of automatically and
> transparently dealing with a protocol, inspection and intrusion are
> what characterize screen-scrapers. The approach attaches  significance
> to application data that has no definition within the protocol or the
> application. To compensate for the lack of meta  data available,
> screen-scrapers invent their own product specific application lexicon.
> A guess at application meaning by one product  is as good as another
> I suppose but hardly acceptable. Manual programmer intervention is
> generally required to ameliorate  misinterpretation of application
> data with screen-scrapers which consequentially introduces a
> nightmare test scenario of immense  complexity coupled with interface
> fragility. In contrast, application meta data is readily available on
> host servers providing  current, formal and accurate definitions with
> no redundancy or deployment issues.
>
> > 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.
>
> I have never consider iSeries applications to be of swine, wrote
> a few myself-). What do iSeries companies do while awaiting your
> "industry wide reengineering" to happen? Logical transitions not
> conversions are required;
>
> - Web access to thousands of existing "green-screen" applications
> - No double-maintenance
> - Existing displays to include graphics, text, and links
> - Utilize existing tools and skills to develop new Web applications
> - Clients not restricted to a particular emulator or operating system
> - Complex Web applications that need to save state through a series of
>   steps easily done
>
> Tools are needed that do not cost the earth, are load-&-go and require
> no intervention dealing with existing applications.
>
> >
> > 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!
>
> Always been a modular sort of guy, makes sense and is achievable.
> Display files "externally described" are modular and facilitate
> reuse  by variety of application units. Do not get your point?
> Again, assumptions about current technology options, what you
> describe is possible, just need to revisit some older technology
> with new eyes and exploit proven web standards. Who knows someone
> may just do something specific for the iSeries that achieves this...
>
> Illusions are not sustainable, pork usually ends up roasted...
>
>
> Bob