Frontier as a scalable XML repository (was Re: Is XML dead already or what?)

[Deke Smith]

As someone who uses Frontier with XML I will try to make a brief outline 
of my experiences (I can get a little verbose sometimes).

Frontier is a good example of how some people use XML in a PRODUCTION 
ENVIRONMENT. All the users of the current version use XML whether they 
know it or not. As part of a subscription to Frontier, the user is 
provided constant updates for bug fixes and new features. Those updates 
are provided via HTTP using XML. The documentation can be downloaded and 
referenced from within the program and that, too, is updated the same 
way. Both of these uses of XML are invisible to the end user...

I think many people who are currently using Frontier as a processor for 
XML would agree with this:


Tyler Baker, tyler at infinet.com said on 2/1/99 11:56 AM:

>There seems to be a major misconception here I think in terms of what 
>software
>needs to do for businesses.  The issue for XML I think should be 
>scalability, not
>just raw speed.  What use is the XML/XSL architecture if it costs mucho 
>deneiro
>in development dollars for fly-by-night consultants, overpriced databases, 
>and
>application servers.  Maybe some giant bank has money to burn, but the 
>average
>web-shop if they are even profitable is running their business on very thin
>margins.  Raw performance of using XML is not what should be the focus here,
>simplicity should be the focus.  

In a production environment where expediency is important as well as 
flexibility and reuseability, *TODAY* XSL is not the answer. If I am not 
mistaken, XSL is still in working draft. I have based work I have done on 
a working draft before and had to redo it later to be reuseable. There is 
a need, and tools like the Xmltr Suite have filled the vacuum in the 
Frontier environment.

I have tried to see how much XML Frontier can munch on and used the 
religion xml files as a stress test. Last time I tried (three months ago) 
Frontier could not parse that quantity of text at one time. It coughed a 
hair ball about a quarter of a way through it.

As far as being a repository for terabytes of information...that is an 
interesting question and one that sounds intriquing enough to try. 
Parsing huge files may be a problem as I mentioned before. Although most 
of Frontier's information is stored in the main database of the program 
called the 'root', 'guest' databases can be created as needed. 
Unfortunately I don't have a terabyte disk drive nor do I think I can 
scrounge up a terabyte worth of information on my own to try.

I search for XML data once it is inside of Frontier by creating indices. 
Right now, indices are pretty much a roll your own proposition.

I have a database of approximately 1,000 contacts from around the world 
in an XML file. That way, it can be edited by volunteers who have no 
computer experience on Mac, Windows, Unix, BeOS, etc. I can bring this 
data into Frontier and create a "Yahoo-style" directory from the 
information with about a hundred pages. I also can replicate the 
directory in Spanish and German using XML-based dictionaries to translate 
geographic names and interface elements. After creating my scripts, it 
takes me about thirty minutes to bring the revised listing into Frontier 
and get it started. A couple of hours later it is done and the Website 
online has been updated via FTP.

Deke

-----------------------------------------------------------------
Deke Smith
Tallent Communications Group, Brentwood TN
deke at tallent.com, 615-661-9878

"Cats are smarter than dogs. You can't get eight cats to pull a sled
through snow." 
       - Jeff Valdez
-----------------------------------------------------------------



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)