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

W. Eliot Kimber eliot at
Sun Jan 31 15:57:00 GMT 1999

At 06:17 AM 1/31/99 -0800, Dave Winer wrote:
>>>That's good--but does that apply to templates as well? 
>BTW, Frontier is not primarily even a web server. It's a content management
>system. Organizations often serve on other systems.

You're right--I remember now that the tutorial talks about publishing the
Web site out of Frontier and onto the site, which often makes sense,
although sometimes it makes more sense to do that publishing dynamically
(thus my reference to CGI commented on below).

>I'm sorry I can't handle level of request for feedback at this time. I
>think you've figured out the reality. We do systems for web content
>management. That's our focus. In 1997 and 1998 we added a lot of XML
>support. It hasn't been integrated into our marketing materials. We don't
>know to talk to people like you. We want to learn.

Always encouraging--I hope my feedback has been helpful.  As an integrator,
I'm always willing to provide constructive feedback on promissing tools in
the hopes that I'll be able to provide better solutions for my clients.  

>About your cynicism about delivery based on experience, please don't give
>that to us. We do deliver. This is Frontier 6 in the pipe, not Frontier 2. 

I was being a bit facetious, but remember too that I've been burned more
times than not.  It's like being told as a kid for the 10th time that
"we'll go to the circus next weekend"--after a while, you stop believing
it, no matter how credible the source.  My firm policy is "I'll believe it
when I see it and no sooner". 

>Frontier has nothing to do with CGI scripts! How could you have gotten that
>impression? (OK, we can do CGIs, but that isn't what makes us special.)

I had confused the publish-time scripting Frontier provides with the
sever-time scripting CGI provides. But the two are really the same process,
just done at different times in the delivery process. Which you choose is
entirely a matter of performance optimization (for the most part). Ideally,
the server would give you a way to define the generation rules once and
manage the binding time transparently. Don't know if that's practically
realistic--I suspect it's something that has to be managed by human

>OK, anyway let's try another tack..
>Look at this site:
>This may be closer to what you're looking for.
Will do.

>One final note, thanks for the kind words about the reliability of the
>software, and the fact that we don't ask you to reboot. We fought hard for
>that kind of simplicity. We don't show the first-time user everything we
>can do.

Of course not.  All general tools have way more capability than can be
usefully explained on a Web site.  And of course, the developers can never
fully appreciate the full potential of the tool, simply because they're too
close to it and have too deeply internalized their view of how it can and
should be used. This is why users and integrators are so important--they
will find new and innovative ways to apply the tool.


<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004

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

More information about the Xml-dev mailing list