Hide full article
ProVUE Panorama is a remarkable database application that we've been following in TidBITS for over 15 years. You may already know from my in-depth description (in "Seeing the Light with Panorama", 2001-11-19) that Panorama keeps all its data loaded into memory, so searches and other data manipulations are fast (because RAM access is fast) and safe (because nothing changes on disk unless you explicitly save). Also, Panorama lets you create fancy windows for accessing data, using text fields and buttons and scrolling lists and menus and so on - indeed, with its massive built-in programming language, Panorama is no less than a database software construction kit, reminiscent of HyperCard or
REALbasic - and yet at the same time, Panorama remains easy to use because you can always just view your data in an Excel-like grid.
In other past articles, TidBITS publisher Adam Engst has told how Panorama became his database of choice for managing Take Control financials (see "When You Need a Panoramic View", 2005-03-14), and has described an interesting ad hoc use of Panorama (see "An Unusual Use for Panorama", 2005-04-11). Indeed, "ad hoc" is one of Adam's favorite phrases to describe Panorama. You don't have to plan out your database's scheme in advance. There's always your data in that grid, so you can always just grow the data and use the grid, add another database with another grid and hook them together, and worry later about any specialized ways of accessing
or manipulating that data using windows and the programming language. Just this morning, in fact, I fired up Twitterrific and there was Adam saying: "Phew - finished [Take Control] royalties finally! Had to tweak databases around for resellers and shared editor percentages. Getting complicated... But I love working in Panorama for this sort of thing, since it's easy to create new databases and enhance them slowly as I need more stuff." In short, Panorama keeps us going, in more than one sense: we rely on it, but also it encourages use.
This notice is to report that with its latest version, 5.5.1, Panorama has broken through into an entirely new world, called Panorama Enterprise. After years of development, and supported by lots of user beta testing, Panorama now operates over a network. I haven't actually tried this yet, but after surveying the documentation and talking with developer Jim Rea, here's how I understand it. You have a Panorama database, and multiple copies of Panorama. One copy of Panorama sits on a network, either locally where it can be accessed through Bonjour, or remotely where it can be accessed through a static IP address, and is designated the server - meaning that it is the keeper of the master copy of the database. Other copies of Panorama on
other machines also have a copy of the database, and let the master copy know when they make changes.
That's a somewhat unusual architecture for a database - and therein lies its brilliance. Most client-server databases have just one copy of the database, the master copy. It sits off remotely on some computer, and when you want to see the data, or search it, or change it, you talk to the remote computer. You are, in effect, merely using your local computer as a dumb terminal for the remote computer; the remote computer is where all the work actually takes place. Not so with Panorama. Panorama is more like... well, it's more like the Subversion version control software, which we use here at TidBITS for cooperative editing of articles. Remotely, there's a master copy of the database, being
maintained in memory so it's fast; and meanwhile on your local computer there's a local copy of the database, also being maintained in memory so it's fast too. To search the database, you just search your local copy, which is as fast as it gets. At the same time, your local copy is always up to date, because it constantly hears about any changes that are made to the master copy.
And how are changes communicated to the master copy? Well, if user A starts editing a piece of data in his local copy of the database, the master copy hears about this and "locks" that piece of data momentarily so that user B will be warned off if he tries to edit the very same piece of data in his local copy of the database; when user A is done editing, the change is copied up to the master copy, and the lock is taken down. (Again, this is like Subversion - at least, it's like the way we at TidBITS use Subversion.) But does this mean that user A can't edit the database unless he's connected to the network? Typically, yes; but if he really wants to, user A can edit his copy offline, and when he comes back online, his changes
will be synchronized up to the master copy. (Of course, if user B has meanwhile changed the same data in the master copy, there's a conflict; Panorama will inform user A of this, and can let him reconcile the problem by hand. Boy, this really does remind me of Subversion!)
However, a Panorama database consists of more than just data: it also has "forms" (windows where the user can view and edit data through a graphical user interface) and code (e.g., what happens when the user presses a certain button in a certain form window). We don't want it to be necessary to design and freeze all of that ahead of time; rather, the database should be free to evolve and be developed over time in the ad hoc manner favored by Adam. And that's just what happens. The Panorama programmer develops and tests the new functionality on his own copy of the database and then, when everything is ready, he instructs his copy to mirror itself up to the server. Database sharing users who connect to the server after that point then
receive a new copy of the database with all the new functionality. Obviously that takes more time than just sending individual cells of data back and forth, but it's likely to be a far rarer occurrence, and an occasional automatic download of this type is a small price to pay for being able to inherit the database's yummy new functionality.
Okay, so Panorama's server-client architecture lets a database be distributed among multiple Panorama users. And the master copy of Panorama works over the Internet by sitting behind a Web server (Apache, included in Mac OS X). So now you're probably thinking to yourself: "Hey! Panorama should be able to do more than just share a database; it should be able to serve Web pages, too." Well, it can! Thus, instead of coming along with another copy of Panorama, someone can come along with nothing but a Web browser, and can potentially view and edit data in the master copy of the database. Of course, it's up to you to program into the database the rules for whether and how it should respond to Web browser requests. In other words (drum roll,
please), Panorama is now not only a software construction kit, it's also a Web application construction kit.
If this sounds exciting to you, as well it should, your next step should be to head for ProVUE's newly revamped Web site to learn more. Check out the page of quotes from businesses that have been beta testers during the development of the server-client ("Enterprise") Panorama architecture - including the tale of how Panorama was used to manage the visual effects for the 2007 movie "300." The best way to become familiar with what Panorama is and to start imagining how you might use it is to watch the screencasts; then download the whole thing and peruse the extensive and gorgeously rewritten documentation. The download, by the way, is a free 45-day trial, extended to 101 days if you use coupon code TIDBITS8722. The trial works for both Panorama and a 2-user version of Panorama Enterprise with Web publishing capabilities.
Panorama requires Mac OS X 10.4 Tiger or later. Pricing can be a bit complicated, as it often is with powerful multi-user databases, but let's see if I can summarize coherently.
The bottom-of-the-line product is called Panorama Direct; it can search and manipulate and edit and add data in a Panorama database, but it has no authoring capabilities - you can't use it to write Panorama code or create window-based forms for viewing the data through a graphical user interface. It costs $129.95. For authoring capabilities, you need a copy of full-fledged Panorama itself, which costs $299. So you may imagine that in some small company you might have one copy of full-fledged Panorama, for your database programmer, and everyone else gets a copy of Panorama Direct.
For distributed database sharing, you need a server copy of Panorama. Pricing here is governed by how many copies of Panorama can be connected to the server simultaneously. For example, a server that lets up to three copies of Panorama connect to it simultaneously is $399; then there's a six-copy server, and a twelve-copy server, all the way up to a server that lets an unlimited number of copies of Panorama connect to it simultaneously, which is $1,999. It's important to stress here that Panorama Direct can be a database sharing client! So, again, our small company might get by with a 3-connection server, a single copy of full-fledged Panorama for development, and a bunch of copies of Panorama Direct; the worst that can happen
is that while three Panorama Direct users are using a shared database, a fourth might try to connect to the server and be turned away temporarily.
What if you want your Panorama server to serve Web pages? That's $899, and includes the ability to share a database with one user simultaneously (essential, since otherwise the data and programming could not be modified on the server side). If you combine this ability with database sharing, you start to get some discounting, plus there are various volume discounts for multiple copies of Panorama. All of this may sound pricey if you haven't been paying attention to the cost of commercial database sharing software, but it turns out to be considerably cheaper than parallel functionality for, say, FileMaker or 4D.
and Adam C. Engst 
