Vignette

This document has been superseded by http://www.photo.net/wtr/vignette.html. I keep this old one around because it was a fun piece of writing. The key issue is "how closely does your Web tool suite model the business that you want to be in?". In the two years since I wrote this article, Vignette has built some higher-level software than the mere Web/db connectivity layer described below. I've actually been doing this myself for a broad class of Web service operators with the ArsDigita Community System (free, open-source, and driven forward by 40 developers at arsdigita.com). Note that my book chapter describing the system does not even mention the Web/db connectivity issues discussed below. They really aren't relevant in the grand scheme of things. Looking at Vignette also gave me a good idea for a problem set for my students at MIT: http://www.photo.net/teaching/psets/ps3/ps3.adp.

Why am I reviewing a product that is at least two years behind the state of the art? Because Vignette has somehow managed to attract sufficient funding and PR that people occasionally ask me for my opinion. So here's an edited version of a report that I wrote for a client in August 1997 after a meeting with Vignette's sales and tech people.

What it does not do

I could laboriously evaluate Vignette against the criteria that I laid down for Web/DB integration tools in Chapter 12 of Database Backed Web Sites . However, I think I'll restrict myself to a few key points instead.

Caching

The wizard programmer: figures out a very fast mechanism for a dynamically generated Web page to get to the RDBMS. (AOLserver)

The smart programmer: tries to build a very fast mechanism for a dynamically generated Web page to get to the RDBMS but fails and ends up with a needlessly pokey one instead. (Netscape LiveWire; Oracle WebServer)

The stupid programmer: can't figure out this RDBMS thang and resorts to stuffing the results of queries into the Unix file system.

The idiot programmer: can't figure out this RDBMS stuff so stuffs the results of queries in the Unix file system. Then goes and patents the idea. (Vignette.)

Yes, what Vignette does is, the first time someone requests a page, the code written by the publisher's programmer is executed. It may query an RDBMS. When the page has been built, it gets delivered to a user and then stored in the Unix file system. Should another user request the same page within a specified time period, the HTML is delivered from the Unix file system rather than by running the Tcl code and querying the RDBMS again.

Fifteen minutes of thinking about this architecture makes one realize that it is totally the right thing for Sun Microsystems. Data comes from the disk subsystem. It goes into Oracle's shared memory cache. Then it goes into Vignette which writes it back to a different part of the disk subsystem. Then it comes back out of the disk subsystem and into Vignette before going out the Netscape Enterprise Server to the client. You need a computer with about twice as much RAM and disk/RAM bandwidth than if you just did the obvious thing and served db-driven pages on the fly.

Let it be noted that caching outside the RDBMS is not always a bad idea. If one is using a low-grade RDBMS or depending on data from foreign servers (see The Bill Gates Personal Wealth Clock), then caching in the server program's virtual memory can be an excellent idea. I spent ten minutes writing a general-purpose Tcl memoization function that I use for caching portions of pages.

For modern Web services, this kind of caching isn't usually make-or-break. The whole point of Web service design is that you personalize pages. Server-side caching of a big page that you built for Jane Doe won't be of any use when you're serving Joe Foobar. So even if the Vignette caching scheme were better-implemented, it wouldn't be of any use for most parts of a modern Web site.

No Data Model

This was actually the most useful part of the meeting. I studied the success of Vignette's marketing literature and began to think about what it would be like if one actually built a product like the one they imply they have. Check out the system I designed and have (mostly) built.

No Session Variables

No Expertise in Document Management

One of these "real document management" companies (Basis; http://www.idi.oclc.org/) didn't feel like dealing with Oracle, et. al., so they wrote their own full-blown RDBMS from scratch.

No Product

Summary, Sort Of

Brave New World

philg@mit.edu

Reader's Comments





-- Christopher Traynor, March 1, 1999

After reading the complete documentation i just could not understand what exactly Vignette StoryServer is.I'm a ASP professional.How can it will be useful to me? and you are saying that TCL programming...what it is...And this Vegnette Server is compatiblle with ASP(Active server pages)...please send me the mail with all details... Regards Ramchandrareddy.r



-- ramchandrareddy rupireddy, December 20, 2000

The review of Story Server is quite outdated... The product now offers extensive content managment, personalization and cache management. Yes, cache management is important... if you perform a database operation for every page generation then you still need to get that information from the database, process it, format it in HTML, then deliver it to the client. With Vignette's patented cache management, the generated HTML is cached, and hence delivered without the processing overhead. This is part of what the industry calls scalability.



-- Sakes ForHire, January 26, 2001

This is a rather simplistic and biased view of Vignette. From programming in tcl off and on for the past 5 years, it is simple and felxible enough to provide a custom Content Management App. in a relatively short period of time. Further customization of this software would create a "Microsoft-like" product, totally inflexible and full of bugs.



-- Chris Pena, February 11, 2003