OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] The Browser Wars are Dead! Long Live the Browser Wa rs!

[ Lists Home | Date Index | Thread Index ]

From: Paul Prescod [mailto:paul@prescod.net]

>Fortune 500 companies spend hundreds of millions of dollars on the 
>development of core business apps that run in web browsers. You believe 
>that you understand the industry better than the people who build those 
>apps because you use FoxPro (of all things).

Which industry did you have in mind?  Ok, let's 
take the one I work in.  I'll take this from 
an RFP of average difficulty in this industry and 
only include one of the systems, the records 
management side. 

From scratch and on your own nickel, build 
a commercial relational database system for 
large multi-juridictional agencies.
It uses approximately 250 related tables, 
about 200 forms, 5500 fields, 24x7x365@99.99 
reliability real time. The table/form/field 
requirements expand with every release.

Ensure it is customizable by the customer, thrives between 
version releases (same reliability numbers), has store 
and forward interfaces among legacy systems, provides a user-friendly (say 
idiot proof) report generator, ad hoc querying, integration 
with existing document systems and Corel and MS Office, magnetic stripe 
readers, automatic fingerprint systems, bar coding, has field level security, 
multi-agency applicability, data mining, and provides rapid 
response (has to be about a second and half or 
less for average operations and that is worst case even 
for complex queries with multiple joins).  

It has to support command line interfaces as well as GUI, 
meet HIPPA Federal security requirements (absolutely 
cannot be hacked), allows all Geofiles to be updated 
by non-technical personnel, and provides a master clock 
for the network system.  These are just some requirements 
but they provide a flavor.

Now maintain it at hundreds of sites.  Scale counts.
Release a new version at least twice a year including 
features both from existing customers and managing 
the requirements of all new customers.

Keep reselling it in a market where the average system 
sells at about 1.5mil (include the hardware) but your 
clients and servers sell in the range of 100k. This is   
not a toolkit to develop tools from, but a near 
shrinkwrap installed application with a cutover that doesn't down 
the existing system (remember you have to do data conversion 
too but you can charge more for that).  

The customer might have an IT department 
but don't count on it.  This is not a custom-built system, 
but one that has to be sold as a commercial product in 
a market with at least six tier 1 competitors  
and dozens of tier 2 competitors.  The same system 
has to work for a very small or very large department
with installations having as many as 1000 real time 
concurrent users doing not just access, but the whole range of 
SQL operations (and don't forget, 1.5 seconds).

BTW:  there is no such thing as an industry standard 
for the data model; just some stuff for the 
admin reporting chain, essentially, statistical data.  
A common schema? Fagedaboutit.  Interoperation with 
competitor systems?  Not likely but when it happens, 
delimited ASCII is de rigeur.  Common API? Say ODBC.

Keep in mind, heroic effort might succeed once.  
Twice is dicey.

As for FoxPro, it wasn't my choice, but once I learned 
Fox, the sense of it was obvious.  Years and years of 
experience went into developing a dedicated relational 
client that has the performance required and enables 
professionals to build fast, test, and field.  Hard to 
do with Frontpage.  Impossible in the ASCII editor.   

The tools are there because they make the big projects affordable.

It is easy to embed a web browser object in a form, and for 
some tasks, that is the right solution.  Again, my 
cut here is not against the web or the browser, but 
against the naivete with which they are presented as 
the only way to build systems these days.  Browser-based 
solutions are not a complete answer, part of one, 
but not the whole.   So again, what I am looking 
for is creative thinking on the subject of frameworks 
that are web and XML capable, but only as needed.

What I heard in Cagle's description of Box's speech 
intrigued me.  It was as if someone was actually taking 
the time to do some serious what-if thinking about 
a new generation of very large distibuted computing 
frameworks not hamstrung by the legacy of a 40 year old 
stateless network architecture designed for nuclear blowout.
What I read about XDocs is intriguing because it appears  
to make the web available to the other components without
dragging around what for some applications is the useless 
overhead of HTML but integrates WYSIWYG like document 
editing with structured relational data.  Sounds Good.  
Waiting to see what these are.  Otherwise, back to hacking Fox.

Yes, they spend hundreds of millions on core systems 
running in web browsers.  Some of them are spending 
it twice because they really believed they were getting 
a zero-footprint, zero-install system and forgot to 
verify that the technology applied could actually 
accomplish the job at hand.  They under-spec'd, 
believed what they heard and signed the procurement.  

Here's one to ponder from an RFP on my desk:

"Must support XML output without customization."

That's the whole requirement for XML in an RFP 
of over 300 pages.  ROTFLMAO.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS