Re: webfacing and competing products

["trevor perry" <trevorp@xxxxxxxxxxxxxxxx>]

Ok, ok, I got "servlets" wrong. I meant applets, and I said both.

This is what I see. RealPlayer is a fat client. QuickTime is a fat client.
Flash is a fat client. The JavaVM is a fat client. We use fat clients
everywhere. Applets are a fat client. Some are fatter, some are skinnier.

And I will say it this way. I assert, i you are just putting the same 24x80
from the (ex-)DSPF to a client - browser or otherwise - you are
screen-scraping.

----- Original Message ----- 
From: "Nathan M. Andelin"

> > from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
> > I'll add that they're all a technological dead end, because they
> > rely on the 5250 data stream.  That's what makes PSC/400 so
> > much different and in my mind so superior.
>
> I agree that PCS/400 is different.  Screen scrapers extract data from
> pre-formatted streams before applying their own formatting, while PCS
> essentially transforms record buffers BEFORE any other formatting has
> occurred.
>
> Perhaps Trevor's point was that a *DSPF still defines the formatting, and
> that the user interface is still tied to the original *DSPF.  Actually,
> Trevor seems to be struggling with understanding "thin" vs. "thick" client
> architecture.  The assertion that Servlets are "thick" seems totally
> off-base.
>
> My feeling is that screen scraping may be strategic to the extend that
5250
> is still strategic.  The biggest advantage of screen scraping is support
for
> IBM menus and commands, which are so tightly integrated into business
> applications.
>
> A large number of our software support calls were answered with
instructions
> about using WRKWTR, WRKOUTQ, WRKSPLF, WRKCFGSTS, WRKUSRPRF, etc. which our
> applications heavily relied on.  Anyone deploying an alternative to
> screen-scraping has those issues to deal with.
>
> Yet, if the strategic goal is to move applications toward the
> Model-View-Controller design pattern, while adding point-and-click
> navigation to the user interface, then it seems to me that any tool
> dependent on existing "display" files is probably a temporary solution.
>
> Nathan M. Andelin
> www.relational-data.com