By Jeffrey Carl
Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.
“Jabber” and “Zope” sound like two characters from “Alice in Wonderland.” Or maybe characters in Quake II (“jabber saw the light from zope’s BFG-10K”). Either way, what they really represent are attempts by the open-source community to beat commercial offerings in emerging critical Internet areas: instant messaging (IM) and web application development.
Can they do it? On one hand, projects like Apache and Linux or *BSD have shown that open source software can lead the industry in performance. On the other hand, both projects face the perennial Achilles’ heel of open-source projects – lack of commercial distribution channels and a corresponding difficulty in gaining enough market share to become a standard. Let’s take a look at both projects, how ISPs can use them, and whether they can beat the big commercial packages.
Jabber
Once upon a time, there was Mirabilis ICQ (“I Seek You”). And lo, it was good. Then it was bought by AOL and became the basis for AOL Instant Messenger (AIM). Then Microsoft’s MSN and Yahoo! got into the act with similar programs that could communicate with the zillions of ICQ/AIM users. Then AOL said, “Oh no you don’t.” Then Hell froze over and Microsoft started complaining to AOL about “open standards” and MSN et. al. whined to Congress about it…
Right now, IM is a mess. AIM, with an astonishing 45 million users, holds tight to its grip on ICQ, keeping its service proprietary. Few people are inclined to shed tears for Microsoft because it’s being disadvantaged by proprietary systems. Still, many users are seeking an IM program that, like J.R.R. Tolkien’s “One Ring,” would “bind them all together.”
What is it?
There are plenty of open-source ICQ clones (like LICQ [www.licq.org], popular on Linux). Jabber is quick to point out that it isn’t just another ICQ clone. As the project’s FAQ page says:
Put simply, Jabber is an open source, cross-platform, completely extensible, end-all to Instant Messaging as we know it. Never again will you have to worry about finding the right client to talk to your friends, nor will you have to concern yourself with having three or four different clients open so that you can chat with all of your associates. And all you have to do is pick the client that you like for the platform you want!
Jabber is genuinely different from other instant-messaging products, although the differences are “under the hood.” A Jabber user gets an account with a Jabber server, and the server then takes care of all the “heavy lifting” – communicating with other servers and translating the protocols of other IM systems into Jabber’s own XML (eXtensible Markup Language)-based messaging protocol. In theory, server modules can be written to parse any other IM protocol, and connectivity to those systems is then automatically provided to the client.
How does it work?
Joe User gets an account with a Jabber server. He also gets accounts with AIM and Yahoo! Pager. His Jabber server stores his account info and “buddy lists” (roster) for each IM service, allowing him to access all of them through his one server and one client. Assuming that the server has the requisite protocol “transports,” he can then communicate with users of any of these services from his Jabber client.
The native Jabber protocol is an XML stream over a TCP socket, allowing for a number of possibilities for how and over which port it can be sent (a bonus for its potential ability to evade firewalls, critical to the success of any IM protocol). The Jabber client communicates only with its server, which then handles all of the protocol-translation and communication issues.
What’s so great about it?
Obviously, the ability to communicate with any IM protocol is a huge plus, potentially making Jabber the “holy grail” of IM platforms. Also, its reliance on the server model simplifies matters for users significantly.
While it promotes unity among IM protocols, Jabber also promotes competition within its own ranks, and Jabber users can choose from a number of different Jabber clients, each with their own foci, strengths and weaknesses. Its open standard and protocol means that anyone who would like to create a new client or offer new features can do so with (relative) ease.
Also, Jabber is intended to be cross-platform. Work on clients is reportedly underway for *nix on command line and X-Windows, Win32, MacOS, browser-based, and even Newton.
What still needs work?
As of this writing in mid-April, just about everything. Jabber is still very much a work in progress (its server has yet to reach 1.0 status or implement working transports for other IM systems), and it remains to be seen a.) how well its compatibility with other IM protocols will work, and b.) how well it will work by itself. Most of the clients are still missing some user-interface niceties, and a working standard for security/encryption of Jabber messages has yet to be implemented.
Jabber is like Rambus – one of those long-shot bets which will either take over the world or be a perennial also-ran. It has all of the right ingredients, but only time will tell whether it fulfills its promise.
A critical hurdle is the same interoperability issue which has plagued other IM clients: will AOL try to block it? AOL’s ICQ users are such a tremendous asset to AOL that it’s hard to imagine that AOL won’t try to block Jabber out if it gains much share of the market. The jury is still very much out on Jabber’s eventual success … and whether, if it can’t communicate with others, it can succeed on its own.
Zope
Zope (the “Z Object Publishing Environment”) is … well, it’s hard to describe in a hurry. But it’s very cool.
What is it?
It describes itself as an “application server,” and its goal is to provide a framework for creating and maintaining large websites with advanced functionality like site users, feedback and content databases. Elements of Zope (currently at version 2.1.6) compete with both higher-end commercial software like WebObjects or Cold Fusion, as well as open-source site spinoffs like slash (the source code for the backend to slashdot.org).
Zope is portable, since it’s written in Python (with some performance-critical parts in C); currently, it runs on Windows NT and nearly any Unix. Installing and running Zope requires that you have Python (http://www.python.org) version 1.5.2 or higher installed on your server. It requires Python to be built with threads support; if you’re installing Python to use Zope, be sure to run the pre-installation configure script with the –with-thread option.
Zope began life in the Bobo Web Object System, developed by a company called Digital Creations (http://www.digicool.com). The Bobo framework was open-sourced, while the company sold a commercial application server based on it, which was named Principia.
Seeing that the application server market was dominated by big names whose marketing muscle Digital Creations could never compete with, the company decided in December 1998 to combine Principia and Bobo, rename it Zope, and open-source the whole shebang. Zope began to gain recognition and users, while Digital Creations shifted its business model to providing commercial support and consulting for Zope.
How does it work?
The heart of the system combines an ORB (Object Request Broker) with an object database, allowing pages to be simply and dynamically created. The main components of Zope are:
• the ORB, which extracts information from the database
• the object database itself
• the publisher, which interfaces with a web server
• the template system, for dressing up content in your customized page templates
• the management structure, which handles authoring/access permissions
Here’s the short, short version: you download Zope to the server where its content will be server from. Zope is available as a Windows executable, in RPM format for Linux, or tar-gzipped source archives for Solaris, Linux or any other *nix. For a quick start, just run the Zope setup script, then run the start script it builds, and away you go. Zope launches its own web server on the port of your choice (default 8080), although you can easily configure it to use Apache, IIS or another server.
You can then use a web browser to view pages or go to its “manage” interface. Using these controls, you can create new folders and add content to them. You also use the manage interface to assign basic functionality (who can access or alter the contents, HTML templates and error messages, etc.). This interface also provides “approval” and “undo” functionality as well.
The content comes in the form of … well, lots of things – users, images, or other items usable by the database. Primarily, though, it will be DTML (Document Template Markup Language) objects, which can contain XML, DTML or good plain old HTML. DTML works like server-parsed HTML on steroids, offering very advanced functionality. An example might look like this:
<!–#var my_header–>
<!–#if “AUTHENTICATED_USER==’Jeff'”–>
<h3>Here is the customer list:</h3>
<table>
<!–#in showCustomers–>
<tr>
<td><!–#var cust_name–></td>
<td><!–#var cust_type–></td>
<td><!–#var acct_balance–></td>
</tr>
<!–#/in–>
</table>
<!–#else–>
<em>Sorry, you can’t read this!</em>
<!–#/if–>
<!–#var my_html_footer–>
And there, you have a complete, well-formatted HTML page. The DTML page above calls in an external HTML page header that you uploaded named my_header, checks to see if the user has permission to view a table, and if so calls an object which is a SQL query that you defined earlier called “showCustomers” and displays the results in a table. If the user viewing the page isn’t the one it expected, it prints an innocuous HTML message. For everyone, it then prints the external HTML footer you named my_footer.
All of this can be easily done with CGI, but learning the DTML syntax is significantly easier for most people than learning Perl or C. Furthermore, the ability to integrate this into a sitewide management structure is a big plus.
So, essentially, with Zope you don’t so much build pages of a site as you build objects of content – FAQs, stories, other information – which get stuffed into a database. You then create folders and pages that are DTML frameworks which can include one simple content object (for a simple, non-dynamic page) or make complicated queries (the last five news objects submitted, all objects submitted by a certain author, the most recent graphic of a certain type, SQL queries, etc.). If you’re unfamiliar with the process, it takes a while to “wrap your head around it,” but it provides a tremendous amount of possibilities.
A very readable introduction that lays out the functional aspects of using Zope (as well as giving a much better explanation of DTML examples like the one above) can be found at http://www.devshed.com/Server_Side/Zope/Intro/. An in-depth look focusing on Zope’s database model is at http://webreview.com/pub/1999/03/05/feature/index2.html. There is an excellent library of pre-built and member-contributed projects that provide example code to learn from at http://www.zope.org/Products, as well.
What’s so great about it?
First, Zope provides an interface to adding/administering the site’s content which is accessible through a web browser. It allows for relatively complex security/permissions setups, which allow the administrator to set access privileges for various groups of contributors (administrators, writers, designers, etc.). Zope makes use of the emerging WebDAV (“Web-based Distributed Authoring and Versioning”[www.webdav.org]) standard to collaboratively manage and handle versions of pages or objects on a site. This also allows for good integration with existing software which supports WebDAV, like Microsoft Office 2000 or Internet Explorer 5 on the client side or Apache with mod_dav on the server side.
Zope provides its own transactional object database, which means that you won’t need to add another database (e.g., MySQL, Oracle, MS SQL, etc.) to provide a back-end. One of the primary benefits to using a transactional (keeping track of additions/changes as “transactions”) database like the one Zope provides is that it allows you to “undo” changes if you need to. The database is optimized to match the needs of most web databases, which are frequently being queried but only occasionally have new data written to them. The Zope database is also easy to back up, and is designed to work with “simple URLs” (unlike those created by WebObjects).
One of Zope’s strong features is interoperability with existing SQL databases. You can set up a Zope database connection to an existing database and apply SQL queries from a Zope DTML page to the older database. Zope also makes good use of XML, allowing interoperation with XML data sources. The Zope database stores a great deal of information besides just your primary content objects; it also keeps track of user postings and threaded discussions, user logins and permission settings, and allows users to customize the way they view the site.
Like any good open-source product, Zope makes very good use of open standards. Aside from WebDAV, SQL and XML, Zope supports HTML 4 and CSS, HTTP 1.1, FTP, FastCGI, DOM, LDAP and other goodies.
Lastly, it was announced in late March that Digital Creations would be open-sourcing its ZEO (Zope Enterprise Option), which can turn Zope into a distributed system. Allowing Zope to scale to multiple machines should make it a feasible choice for high-demand sites which need to be served from multiple machines. Zope has also announced interoperability with Microsoft’s SOAP (Simple Object Access Protocol) sort-of-standard. Whether this will become a “big deal” remains to be seen.
What still needs work?
At first glance, Zope is just plain difficult to understand for most people. The Zope feature tour (http://www.zope.org/Tour/ar01.html) is a good start, and the Zope Guides (http://www.zope.org/Documentation/Guides) are helpful (if understandably incomplete) but some more “hand-holding” higher up in the online documentation might convince more users to “get their feet wet” with Zope.
Zope is certainly on the right track with the emerging standards it uses, but some of these standards will take time to build the user base to allow Zope to really shine (for example, when WebDAV publishing will work from more applications than just IE 5 and Office 2000). The WebDAV standard itself isn’t fully fleshed out yet, and I have to admit that any standard which Microsoft has taken a strong interest in makes me worry a bit.
Lastly, Zope simply isn’t for everyone. If you have a relatively small or simple site, the overhead of learning and serving Zope will probably be a waste of time. If you’re willing to put in the time, using Zope from the get-go will help you scale your site if you need to – but in many cases, using Zope is swatting a fly with a sledgehammer.
The Verdict: Jabber, Zope and You
What can Jabber and Zope do for you? Well, in the short term, you can offer support for them and promote them to your customers. With Zope, ISPs can offer Zope support and make a presence in the small (but growing) market for Zope site-hosting.
With Jabber, ISPs can run their own local Jabber servers. In the short term, it can be used by supplying your NOC with a Jabber nick through which clients can contact them; in the long term, if Jabber meets its promise, your local Jabber server can be a great way to tie users to you (to be Machiavellian, your Jabber server will hold all of their IM contacts and make it a pain to migrate elsewhere).
Will either of these projects ever gain the ubiquity of Apache, sendmail or Linux/BSD? Probably not. But Jabber holds an extraordinary amount of promise, and can be an excellent value-added tool for ISPs – and it’s free – so there’s little reason not to be an early adopter. Zope will almost certainly remain a limited-interest project, but it can be of use to you for your own web sites as well as providing a differentiating service for site hosting.
Can Jabber and Zope beat out the commercial competition? Only time will tell. But, considering the cost (nothing but your time), it’s almost a no-brainer for you to “do the right thing” and support open standards, and to investigate providing support for both with your ISP.
Who knows? If you bet on enough long shots, one of them might turn out to be a winner.