Vignette reviewed by Philip Greenspun for Web Tools Review

Consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they'd leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet.

Two nerds arguing about the best way to connect a Web service to a relational database management system is equally stupid. Web/db connectivity was a sort of interesting problem in 1994 when everyone was using CGI (see the database interfacing chapter of Philip and Alex's Guide to Web Publishing). It became a completely uninteresting problem after it was solved in 1995 by AOLserver (then called NaviServer), whose connection pooling scheme and interpreted language API improved performance by roughly a factor of 100 over CGI. The irrelevance of even this level of performance gain is illustrated amply by the fact that Amazon.com ignored the connection innovations, continued to use CGI, and cried all the way to a $25 billion market capitalization.

So let's get back to Vignette StoryServer, which I last looked at in January 1999. The software had matured to the point that it does some interesting content management stuff, presumably very helpful to the newspapers and magazines that use the product. StoryServer is also beginning to get into some of the user management stuff that I've spent four years building into the ArsDigita Community System (free and open-source).

The reality is that most publishers spend millions of dollars of time and money floundering around trying to get a Web service started. Before starting anything that might be noticed by a user or contribute to their site's success, the publisher tries to figure out

• which operating system the server should run
• which RDBMS the server should run
• how programs that serve Web requests should talk to the RDBMS
• in what computer languages server-side programs should be written

What most people need is someone to tell them what to do. It is cheaper and better to adopt a false religion than to remain a skeptical atheist, seeking after truth oneself. Of course, it is better and cheaper still to adopt a reasonable religion. If what you want to do is similar to that of Vignette's core clientele, and your organization hasn't done much in this area so far, then you'll probably save a lot of money by adopting Vignette's philosophy.

Random personal note: If you're visiting Vignette in Austin, be sure to drop by SARA Sanctuary, which isn't too far away (in Seguin) and makes a very rewarding day trip.

Well.. when I was looking at working for Vignette, read all Phil's comments and now work as part of the Vignette consulting team. I have been liberally spreading out Phil and Alexs Web Guide and other references to this site. I agree with Phil that the main issue I find with clients are educating them on what web information systems are about and how to provide good information to their customers. The underlying technical issues are not nearly as dominant as the toplevel information architecture and development of business rules.

-- Jamie Ross, July 30, 1999

As much as I like AOLServer, it will never be a product like StoryServer becuase it falls under the scope of most companies. AOLServer needs to take the path that Linux has taken, some company (ArsDigita?) needs to package the thing, support it, and dish it out to corporate.

-- David Peng, August 14, 1999

I have to agree with Phil, I think. I have encountered no shortage of people who could write a better system. My job, though, isn't to use the best possible system, it's to leverage what pieces I best understand right now to get the next product to our customers fastest.

I'm not convinced that we'll be Vignette customers three years from now--they will need to convince us over that time, that our money is getting us the return we need. But right now, using Storyserver is much cheaper than writing my own, and I don't have to worry about maintaining the system once our developer moves on to the next startup. (I do, of course, have to worry about Vignette's developers moving on to the next startup, but that's a different level of anxiety :-).)

And, hopefully, I can move that much faster from conception to serving pages by spending our time worrying about the pages and how our customers work with them.

-- Ari Davidow, September 10, 1999

Before comming yourself to Storyserver, familiarize yourself with it as well as possible. Getting Story is a big investment and in my experience, even the software itself is more expensive than first thought.

Most people are surprised by Story does and doesn't do after they've bought it. Remember it's a tool for building sites and might not actually do anything you want of it without lots and lots of programming. In the projects I've been working with Story, the end cost of the site was more than three times the cost of the software itself due to code development costs of the deployed site (and that's a big wad of cash). Part of the costs came from paying a Vignette consultant who's code wasn't used in the end system. (Think about that.)

Further, at least right now, the system is proprietary in just about everything. Even the TCL interpreter has differences to other systems and even if someone knows other TCL systems, one needs to familiarize with the exact dialect used in Story. If a developer hasn't used Story before, don't think she can start using Story right away no matter her previous experience.

I won't go much in to the speed department of Story. Maybe it will suffice to say I'm waiting for a worse resource hog to come and show it's head on the tool front so I can try and shoot at it.

In it's current form (fall/1999) I don't recommend buying Storyserver. This is based on my experiences but then I've read of numerous success stories of sites deployed with it. That is, read from Vignette's marketting brochures.

-- Sulka Haro, September 18, 1999

Having worked with SS for a couple of months now building http://www.soneraplaza.nl I'm not really impressed with SS. My main problem is the API, everyting is eval-ed, so to get a " into a string when doing a set, you need to double escape it: \\". But when you use the SS IF or WHILE command, which asumes the contents of a command body to be text to be sent to the browser instead of it being a command and interprets only code between [] as a command, that also is eval-ed. So doing a set in the IF command body requires you to do \\\\"! You can imagine what a complex regexp might look like in SS...
If you set a variable in the global scope using [SET] and then setting that variable again in a procedure using the normal TCL set, the SS [SHOW] command (return "" if the variable doesn't exist, instead of an error) will keep returning the global one, not the local one.

There are some things though that I do like:

• The DB driver (which Philip hates). I never have to worry about TEXT fields in Sybase, I can just insert everything with a normal insert and retrieve everything with a normal select. The StoryServer [ROW_INSERT]and [ROW_UPDATE] command are only mildly usefull, as they don't allow transactions, which I need because most inserts are acros a number of tables. But you can simply use [SEARCH TABLE] and execute your dml in there in one transaction.
• The caching is idea is really good, although it could be done more efficiently. But as we speak I am working on the last bits of a few hundred lines of AOLserver TCL code that does the same, only differently.
• When it doesn't crash, the development tool is a good way of working with a lot of people on the same project.
• They have an XML parser

But there are more things I don't like it for:

• It's slow. You really need the caching. Which makes it hard to do what a big selling point for them is: presonalisation.
• All the things described above about the API, and then some.
• The complexity of the system, it's not a server on it's own: Netscape Enterprise or Apache loads a module that comunicates with the 5 SS CAS (Content Aplication Server) daemons, which in turn talks to the DB and the SS CMS (content management server).
• There is one major security bug I won't even go into here, as it concerns our site aswell. Vignette knows about it and basicaly says we will fix it sometime, but for now you should just do some more coding to make it secure...

It is not the great out of the box publishing tool Vignette wants you to think it is. It still requires you to code everything yourself, with their content administration stuff being not very usefull.

I won't say too much about the price of the system though. It's certainly not free but if you're a big site with 5 developers and 10 editors editors and a lot of third party content, the SS price will hardly show up on your budget.

-- Bas Scheffers, November 14, 1999

I worked on a pretty sizable Storyserver implementation in the first part of 1999, and when people ask me about using SS on other projects, I tell them that Storyserver provides two compelling features.

The first is that it dynamically generates pages that are indexable by search engines. When you write things the "Storyserver way," your pages don't require information in the query string to render the correct page, so they're easy for search engines to index.

The second is that it caches pages that don't need to be generated dynamically every time, so it offers decent performance when most of the pages on your site can be cached in this manner. Unfortunately, the trend is toward dynamically generating all of the pages on a site for every user, so this feature isn't very compelling to many potential customers. When we did the Storyserver implementation, we found that we cached none of the pages on the site, although we did cache a few components that were used on lots of pages.

In my opinion, Storyserver is an expensive way to do things that can be done much more cheaply with many other application development platforms. It also forces you to use the Vignette paradigm for your site, and as far as this geek is concerned, that's a bad thing.

Even so, if your site does mesh well with Vignette's idea of how a dynamic site should work, it can lower your time to market considerably. Just remember that once you go the Vignette route, you're locked in to an expensive solution.

-- Rafe Colburn, December 14, 1999

I won't comment on my opinions of StoryServer or Vignette or we'll be here all day. But I do want to comment on what someone else has said relating to StoryServer's "dialect" of tcl and how hard it is to use and learn.

I'm a diehard tcl programmer -- did it full time for 3+ years, and another couple of years part-time before ever even hearing of Vignette. When I took the storyserver class, it was literally only about an hour or two before I was able to create fully functioning web pages customized for individual users, using both built-in storyserver tcl commands and my own commands written from scratch.

Learning the StoryServer "dialect" was a no-op, a non-issue. They have a 100% implementation of standard tcl, with enhancements. I'll admit that the backquoting is odd, but is easy to learn and easy to work with once you understand how and why it works. Again, it took me only an hour or two to understand. And in storyserver 5, it is possible to write templates that do not have the backslash problem at all.

I'll also admit that the scoping issues are unusual, but more often than not make things *easier* on the programmer rather than harder.

As far as I'm concerned, no other like-product can ever be as powerful as StoryServer, specifically *because* storyserver uses tcl, rather than in spite of it. It is extremely powerful for the power-programmer, and extremely easy to learn for the novice. I've seen talented programmers with zero tcl experience be able to come in and be productive in a matter of days, and from my own experience I know that experienced tcl programmers can be productive in a matter of hours, if that.

Frankly I don't understand why so many people misunderstand Tcl. It is used in tens of thousands of applications around the globe, ranging from small embedded systems such as medical equipment and internet routers, to controlling off shore oil rigs and NBC broadcasts.

Not to mention the fact it powers some of the biggest web sites on the net.

-- Bryan Oakley, December 17, 1999

Re: Rafe Colburn's comment: "if you do things the story server way, your pages will be indexed"... because they don't have a ? mark in them, which many engines ignore.

IIRC, thebook notes this potential problem explicitly, and suggests several ways to get around it. Notably, the Zope application server, written in Python, and also open-sourced, doesn't have this problem, since the parameters to a Zope method call are just more things-between-slashes.

Re: Bryan Oakley's observation about tcl: I don't misunderstand it, I just think it's syntax is ugly. If Ousterhout had to design a new language, just to be embeddable, did he have to make it look like *that*? Not that I'm saying I'd prefer Visual Basic for Routers, mind you, but...

-- Jay R. Ashworth, January 17, 2000

OK, Jeroen (above) and I work on the same site. And I have to say that if used correctly, StoryServer can do a lot of things and as said before, the "parameters" inside the URL is a really great thing, both for caching and search engines. SS5 also looks a lot better on paper that 4.2. There's just one thing that they haven't 'fixed' yet: connections to multiple databases. If you use Sybase for your SS db and want to connect to another Sybase db, it's painful (no connection pooling), but possible. Try to connect to Oracle or MS-SQL and things get real ugly.

And although I agree with my colleague that it can handle the load, from an engineers point of view I just don't like doing it with so many machines behind a load balancer. Even though the cost of extra hardware is nothing compared to having a staff of 15+ on your payroll for the site plus an external design company.

If only they fixed the database connections it may even become my system of choice for portal sites like ours. If you ask me there's only two choices now for developing websites: AOLserver and Vignette StoryServer. AOLserver is still king, but VSS is closing fast.

-- Bas Scheffers, January 26, 2000

I have worked with StoryServer 4.2 for over a year now at Schwab. I like it's use of TCL for scripting because it's a good match for string processing.

Unfortunately, I can't recommend the tool. It's lack of good transaction support (they autocommit) and good multiple db support is shocking. This should be the foundation of a good web server side tool.

The system is unnecessarily complex (all the daemons and interprocess communications), which causes side effect problems with cache flush, file dependency checking, slow CMS commands, etc... I feel most of the add on features are marketing fluff. It has version control, but it so basic it's almost worthless. It has built in workflow but try to use it in real life and you'll end up building it yourself. CMS proxies allow you to integrate with the system, but it's slow and can't be included as part of a transaction.

Storyserver 5 is better in that it recycles TCL interpreters, but more core functionality needs fixing. The extra packages are no big deal since they can be found elsewhere (and often open source).

Vignette seems to be VERY good at selling and marketing. Having watched them sell their product to multiple large customers, touting distribute publishing (which involves multiple users writing to a db) without answering the transaction question, I believe they can be profitable.

Maybe it's because large companies have lots of money to spend to get things working. Maybe large companies want 24x7 support from a large vender. Either way, I bought their stock even though I don't recommend Storyserver. 8^)

-- robert chou, April 27, 2000

For all the complaints on this page, there is a sollution within StoryServer.

* Complaints about paying too much for development time I can't help you on. Other than your using the wrong developers.

* If you can't afford vignette, your site isn't big enough for it anyway. Either that or you haven't figured out how to make your large site make money. In which case you have business issues to deal with before technology issues.

* All the problems with escaping quotes isn't necessary, use the tcl subst command.

* If you need to do rollbacks, why not execute a stored procedure that takes in the data and then you can do your begin and end transactions in there.

* With the addition of tclCOM and tclBLEND, I don't think there is ANYTHING StoryServer can not do.

* As for database support. If your not using Oracle/Sybase/SQLServer/DB2 your screwed. I can't imagine spending money on a product like StoryServer, when your not willing to back it up with a decent database.

-- Carson Evans, May 6, 2000

SS has transaction processing. We use a SQL transaction library that talks to vdbtcl which is the DB wrapper around RogueWave. If someone hasn't figure out how to do this, they just have been whining too much and not trying. As far as there not being a wide DB support I'm not sure how a product that supports MS SQL Server, Sybase, Oracle and DB2 is not wide enough. That covers an extremely large install base.

And as someone mentioned, if you're running SS and have not ponied up for a good DB solution you're just kidding yourself.

-- James Paul, June 29, 2000

John Tesh is sueing Vignette for the costs of his StoryServer installation, claiming that "the software was not as advertised"; in fact, the case sounds quite a lot like Philip's old page on Vignette, including the complaint that "workflow support was not built into StoryServer, only the ability to do workflow was built into StoryServer." And ArsDigitans will probably be faintly amused by the plaintiff's description of Tcl as "an archaic scripting language." (The real irony: Inside.com's site, which carries the report, runs on StoryServer.)

-- Nick Sweeney, September 25, 2000

ArsDigitans aren't all THAT amused, Nick. We're not the $%&#* Tcl company. If you check our public CVS tree you'll find that even now you can download a working 100% Java version of ArsDigita Community System. We got tired of saying "we only use Tcl for the presentation layer; the real engineering is in PL/SQL and Java inside the database". It does show one of the advantages of being open-source, though. Nobody who has downloaded ArsDigita software has ever even threatened to sue to get their money back :-)

-- Philip Greenspun, September 25, 2000

I want my money back! I installed the ACS for Linux on my laptop and it worked! What do people think/know about Open Market's ContentServer. I kind of like working with it. It's got a Java API which makes it very functional. It's also got an easy to learn XML scripting langage that maps to java functions. It uses NES and NAS or WebLogic. I hope they come out with their own app server.

-- Bill Moss, September 26, 2000

"Broadvision works"...

Based on both comments from others (linked to, I see when I go to find the page, from elsewhere here), and personal experience with sites as a user, I'd have to say "for sufficiently small values of works." I find myself in concurrence, from an engineering standpoint, with those who say that Broadvision is not especially well designed to do what they sell it for, particularly in light of its competition.

-- Jay R. Ashworth, October 5, 2000

I have read that Broadvision Sucks.

-- Jeff McNeill, October 11, 2000

For a system which is smart about templates and caching, you should also look at the HTML::Mason module which runs inside of Apache with ModPerl. I've met with the developers of Mason and they explained they developed inside their company as an alternative to story server.

Notable sites running Mason include Salon.com, and TheNation.com (!!)

-- Bill Humphries, January 24, 2001

updates for anyone interested:

"Tribune Interactive, which runs chicagotribune.com, is in the process of moving off Vignette to a home-grown platform, as is CNet itself. Similarly, washingtonpost.com is said to be walking away from a reported seven-figure investment in customizing the FutureTense product (now owned by OpenMarket) in favor of a system its employees and contractors are building. 'We couldn't wait for them to fix all the problems anymore', says one person familiar with the washingtonpost.com decision to build its own system. 'There are profound holes in their system, like workflow, which is the most important part of a content-management system. I mean, come on already.'"
The Ugly Secret Behind Top Media Sites | www.inside.com | july 5, 2000 (no longer available)

"Vignette - and rivals like Interwoven TeamSite and Broadvision - still often run a poor second to the do-it-yourself solution. You see, the core content management task is relatively simple: create a database schema in a robust relational database, shove your content into it and whack on a front-end interface to manage elements such as workflow. Except in rare cases, you can skip many of the fancier Vignette features, such as the much-overrated 'personalisation'"
www.shorewalker.com/pages/vignette_doubts-1.html

"I think [the Vignette pricing structure] is highway robbery many times, because clients don't understand how they're being billed. It comes down to whatever they can stick you for. So we've decided to do it all in-house, because it's cheaper for our clients and it's cheaper for us. And it's better. We get exactly what we want this way."
www.siliconalleydaily.com/issues/sar01222001.html#Headline7482

-- danny sofer, May 3, 2001

Update to my rants above:

OK, Vignette Sucks. They never improved anything much, except for a faster page generation in 5.0+.

The Java extensions in 5.5 are just TclBlend and with the way Vignette page generators work a couple of JVMs are started on each server. A typical 2 CPU Sun box will run 16 of them at 50Mb each. Yes that is 750Mb (15x50) of wasted memory. Plus you cannot maintain state between two page requests, one of the great features of servlets.

Java in 5.6 is just calling a 3rd party servlet engine (WebLogic/Tomcat/etc.) to do the hard work, although Vignette does pass the jsessionid this time.

ASP seems to be really stupid as well. It just uses a second IIS instalation to do the work.

They still don't do content management.

Vignette Professional Services (their consultancy) are a bunch of wankers. On a previous project I supposedly had the top dogs from VPS in the UK. They can't code, don't know SQL or data modeling and they wouldn't recognize referential integrity constraints if it hit them in the face. You do not want to know how much time I spent on cleaning up their code and the database.

Caching is still a good thing, but it doesn't mix with personalisation.

I'm just finnishing up on a Vignette project, my last I hope. This is actualy a Java shop but I was hired to lead a project for a Very Big Client that insisted on Vignette. Because I know it so well now and know how to code (ie: "Object Oriented", even thought TCL is a scripting language) it all works rather well. We also had some people from the company that was originaly going to do the project who were surprised at my approach. They would never have been able to do this very complex project the way Vignette wants you to do it. (ie: mix code with html)

If you want to use good technology, either use AOLserver or a good Java/EJB server like Orion.

Vignette and it's competitors only have appeal to dumb-ass CEOs and braindead VPs of marketing...

-- Bas Scheffers, May 16, 2001

Not that I love Vignette, but it's paid the bills the last couple of years. (Now I have to figure out how to avoid being labelled "The Vignette Guy").

Anyway, I put together a string of disconnected observations on Vignette-wrangling that may be of interest here.

-- Stephen Judd, June 21, 2001

I've spent the last year and a half on large vignette projects and am a certified V/5 developer. My complaints regarding Vignette are as follows:

1. Vignette handles static files in such a way that multiple static file operation cause the server to drag to a crawl.
2. CMS Workflow sucks ass. It's buggy, slow, and lacks power. Use database tables and get 100 times better performance.
3. The API Vignette uses with Oracle is extremely lacking and flaky. For instance, the SEARCH PROCEDURE and SEARCH TABLE commands can't handle inserting into CLOBS!
4. TCL is an antiquated language. how many times have you had to use \\\\\\\\\\\\\n for a line feed? There are some good things about TCL, but there are many other BETTER languages out there that can do the same thing just as fast or faster!

OH! and VPS.. I have yet to meet a VPS programmer that knows what they're doing. We hired 2 VPS consultants, and one of them had never programmed in TCL, just ASP.. and niether were certified. What a load of crap! We were paying 200+/hr for these dudes at the time.
I'd like to see a new platform come out with an object oriented back end, built in data access objects, list/menu/search objects, caching, blah blah blah... Before choosing Vignette, do some research!!! I'm sure there is something better out there!

-- Justing Greenwood, October 16, 2001

Justin,

on point 1 & 2: agreed.

3: CLOB/BLOBs are HARD. Try doing them in Oracle in JDBC, or even their own drivers in C, they are a pain in the butt, really. They work fine with ROW_INSERT/UPDATE, though I hate using those for other reasons.

4: I never do \\\\\\\\\\\\n to get a new line. I never use IF and FOREACH, that's why. Don't be put of by TCL just because Vignette's implementation sucks!

-- Bas Scheffers, November 28, 2002

A big OOPS in ALL Vignette/Tcl versions, where the use of [NEEDS LOGIN] allows the execution of arbitrary code. You are vulnerable if you run a public website with that command on any page or have a development CDS (the template previewer has NEEDS LOGIN on top) reachable from the internet.

See http://bas.scheffers.net/vgn-needs-login-exploit.html for a complete explaination.

In all their wisdom, Vignette says they will patch this in V6 (but not 5.0 or V/5). Ofcourse sending out a security alert to all their users is letting them know they stuffed up, so it doesn't seem like they will do that.

You will be surprised at the number of development CDSs accesable from the internet by using Google.And I suspect that is only the tip of the iceberg.

-- Bas Scheffers, November 28, 2002

I just tried to reproduce Bas's NEEDS LOGIN exploit against a V/5 5.6.2 server of mine, and it did not evaluate the Query-String: HTTP header as Tcl code.

-- Dossy Shiobara, January 31, 2003

-- Jon Silvertooth, June 20, 2003

• The previous Vignette page- For those who want the entertainment, here is the previous page, as mentioned by Philip. It's a very literate flame...   (contributed by Parker Smith)

• Detailed Vignette StoryServer Customer Story from Fall 1999 Seybold Conference- Heini Withagen of Netcast discusses his company's (mostly) positive experience with Vignette StoryServer in detail here. He describes how StoryServer was viewed by his company's programmers, sysadmins and customers. Withagen made this presentation at a session titled, "Content Management Strategies: Tools and Processes" at Seybold San Francisco '99, a conference about technology in publishing. (When you read his talk, note that the term "SQL" was mistakenly transcribed as "Seagate", so "Seagate Server" is really "SQL Server", etc.)   (contributed by David Cohen)