Re: Wasting half a trillion dollars?

[Anatole Tartakovsky <anatolet@teamcti.com>]

Stuart,
    One thing I did not mention in my post is HTML, and that is probably
what is causing confusion. Here it goes:
1. I think standard HTML is not usable for application development.
2. Data has to be separated from the presentation on the client - not on
ASP/JSP/Server layer to allow for true application programming
3. New set of rich databound controls has to be introduced and used by
application developers.
It has been a while since I used pure HTML. I could not agree more that
inventors of <FORM> and <FRAME> tags never thought of application
development. However, it has been 10 years, and unless your requirements
include servicing users with Netscape and Opera, you CAN consider browser
for application development.
IE5+ offers behaviors - i.e. custom controls to be packaged as custom tags.
With the advent of their special case of fully encapsulated elements
(viewLinks) you can pretty much close the gap between DHTML and Smalltalk,
PowerBuilder or VisualBasic. What is missing at this point on the market is
a true WYSIWUG designer that would allow you to "plug" custom controls.
XML-based technologies is much better fitted for ever evolving data storage,
manipulation and communicalion of business object model. Complemented with
client-side transform and databinding with custom controls it offers
superior development environment over flat dataset in VB
That said, browser-based technologies offer one real benefit over
conventional client-server. Development process naturally breaks
applications in independent, distributed processes. Remote scripting becomes
natural, and, hopefully, mixture of SOAP and security protocol produces
"secure enough" solution for business Internet.

As far as current, publicly accessible crop of web applications goes, they
are not utilizing the technology/approach described. The closest ones you
should be able to get on your desktop would be Excel for Web(Office 2000) or
Microsoft Investor(www). Please export Excel page as "interactive html page"
and take a look at the "HTML" source.

Thank you for your  input,
Anatole Tartakovsky

----- Original Message -----
From: "Stuart Naylor" <indtec@eircom.net>
To: "Anatole Tartakovsky" <anatolet@teamcti.com>
Sent: Tuesday, May 01, 2001 4:34 AM
Subject: RE: Wasting half a trillion dollars?


> Analtole your totally wrong.
>
> A browser provides a reasonable tool at the moment but it really is a
total
> bastardisation with a plethora of ill fitting standards. I hate HTML and
> believe it should be called NSDB (never the same in a different browser).
>
> HTTP will evolve and the current pages which we view directly will merely
> become data for applications that will eventually become more like
> appliances. The current crops of web apps in a very broad sense are just
> frigs to get the functionality that we require but definately not an end
> goal solution.
>
>
> -----Original Message-----
> From: Anatole Tartakovsky [mailto:anatolet@teamcti.com]
> Sent: 01 May 2001 06:20
> To: Al Snell; Bullard, Claude L (Len)
> Cc: W. E. Perry; XML DEV
> Subject: Re: Wasting half a trillion dollars?
>
>
> I agree that for real world back-office type database enabled applications
> "fat client" beats "server-only" hands down. However, I would not discount
> browser as "the best business application platform". Late versions of IE
> (i.e. 5.5+) CAN be effectively used for "fat client" types of
applications.
> Few things often overlooked by "cross platform/browser" developers:
>     1. IE5.5+ supports behaviors/custom controls that allow complete
> encapsulation of shared javascript code.
>     2. XML support is world-class, with shared code model allowing
> javascript objects within XSL, thus allowing complete segregation of data
> from presentation and high performance model/view controllers.
>     3. Support for business functions such as customizable print and print
> preview and "user settings"
>     4. Customizable HTTPRequest and WebServices allowing true distributed
> model.
>     5. Direct integration of business applications (including Excel and
> Macromedia) via XML
>
> As a matter of fact, in the last few years we were actively converting
> existing client-server applications into the browser based model. We ended
> up with automated conversion process (via XML of course) that was
producing
> less javascript code than the original PowerBuilder/PowerScript
application
> while providing identical look-and-feel, functionality and API for the
> developers. Following are the links to the articles in XML Journal,
> PowerBuilder Journal and XML DevCon 2001 presentations on the subject:
> http://www.sys-con.com/xml/archives/0203/tartakovsky/index.html
> http://www.sys-con.com/pbdj/archives/8-3/rasputnis/index.html
> http://www.xmlsp.com/xmldevcon01/n5_files/frame.htm
>
> As far as Java on the client goes, the upcoming version of JavaScript
> supports object inheritance, implementation of interfaces, precompiled
> distribution and shared run-time with C#, VB and C++. Given the "average
> developer" skill set in business organizations (imho) JavaScript has
better
> chances for "language of choice" for business apps than  the Java and/or
C#.
>
> Regards,
> Anatole Tartakovsky
> anatolet@xmlsp.com
> ----- Original Message -----
> From: "Al Snell" <alaric@alaric-snell.com>
> To: "Bullard, Claude L (Len)" <clbullar@ingr.com>
> Cc: "W. E. Perry" <wperry@fiduciary.com>; "XML DEV"
<xml-dev@lists.xml.org>
> Sent: Monday, April 30, 2001 11:00 PM
> Subject: RE: Wasting half a trillion dollars?
>
>
> > On Mon, 30 Apr 2001, Bullard, Claude L (Len) wrote:
> >
> > > People who tell you a web browser is a perfect
> > > next generation client need to write a few
> > > industrial sized database applications so
> > > they can discover the joys of persistent state
> > > and client side business rules.
> >
> > Aye to that. I hear you, brother!
> >
> > I've developed all too many Web apps now. And yet I remember a
discussion
> > about GUI design (not as in, "where do we put the buttons", but more
> > "writing X windows or MacOS") in which somebody fervently proposed that
> > the GUI software was just a Web browser that handled overlapping windows
> > (eg, it included its own window manager), and then ALL applications were
> > Web apps. He had some odd ideas about the demand for word processing and
> > spreadsheets, I expect.
> >
> > Making all applications emit a Java applet when invoked which runs on
the
> > GUI client and may talk back to the application proper via RMI is a
little
> > more like it, methinks...
> >
> > Horrendous amounts of javascript / DHTML cruft is required to make a Web
> > form work anything like a decent GUI in most cases. This is hell to work
> > with.
> >
> > > Len
> >
> > ABS
> >
> > --
> >                                Alaric B. Snell
> >  http://www.alaric-snell.com/  http://RFC.net/
http://www.warhead.org.uk/
> >    Any sufficiently advanced technology can be emulated in software
> >
> >
> > ------------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org, an initiative of OASIS
> > <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: xml-dev-request@lists.xml.org
> >
>
>
>
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org
>
>