This week, Dominic Amann reports that he has successfully implemented roaming, a feature of Netscape Communicator that enables you to centralize preferences, bookmarks, your address book, cookies, mail filters, and even certificates and keys.
I just bit the bullet and decided (after configuring browsers for the hundredth time) to try Netscape's roaming user setup.
I use Apache on my iServr, and after some trials, I find that it is extremely effective.
Just think: I can take a vanilla notebook, install Netscape, go into Edit | Preferences | Roaming User, fill in about 3 fields, and work exactly as if I was on my favourite macbine! Not bad for free OS, free browser and free server.
This in combo with my iServr on Cable access allows me to work very effectively on the road.
An HTTP-based roaming solution? Clearly I hadn't been paying attention. I knew that it was possible to point Communicator at Netscape's Directory Server, and have it store all the roaming-user data there, but hadn't realized you could also use a Web server for this purpose.
I don't roam that much myself lately, or I'd probably have noticed that Communicator's Edit->Preferences->Roaming Access->Server Information configuration dialog indeed offers two options: an LDAP server, and an HTTP server. A technical article on the Netscape site describes both setups.
The Netscape article naturally presumes you'll use Netscape's Enterprise Server to implement the HTTP option but, of course, Apache is far more popular. As Bruce Elrick pointed out in a follow-up to Dominic's message, there are two options for Apache users: a native Apache module, mod_roaming, and an Apache/Perl (that is, mod_perl) module, Apache::Roaming.
If you're planning to set up roaming, there are two excellent articles online that you'll want to read. One, by Nicholas Petreley, documents both HTTP-based solutions for Apache. The other, by Kartik Subbarao, details an LDAP-based solution using the OpenLDAP server
What if you don't want to do it yourself, though? Wouldn't you think that ISPs should be supporting Netscape's roaming feature?
Bruce Elrick agrees, but points out that such a service would be most useful as an adjunct to server-based email (e.g., IMAP) which many ISPs do not yet offer.
Beyond roaming, Bruce envisions a range of services that would comprise a business-grade offering from ISPs:
From the perspective of a consultant in a small company of consultants, I would like to get a service that provided all [the roaming features we've been discussing], plus group communication (NNTP or shared IMAP forders) using SSL, and configurable to use non-standard ports. The reason for the latter is that I have been in companies that only allow port 80 going out, so it would be nice to do:
IMAP over SSL to imap.whatever.com:80
LDAP over SSL to ldap.whatever.com:80
NNTP over SSL to nntp.whatever.com:80
other web-based apps using HTTP over SSL to www.whatever.com:80Also, guaranteed backups and reasonable security. At a reasonable cost!
I violently agree. eGroups, for example, is offering its modest set of groupware services for $4.95/month. A business-grade solution offering the services Bruce outlines, with robust data protection and security, ought to appeal to a lot of small companies lacking the technical wherewithal to install and configure Directory Server, or OpenLDAP, or Apache with mod_roaming or Apache::Roaming.
As Bruce points out, high-end ASP (application-service provider) services, such as ERP (enterprise resource planning) solutions, can run to hundreds of dollars per employee per month. Although it's expensive to start up an operation like that, the marginal costs should be low. Could the package of services he envisions be delivered economically for $20/month?
It's a puzzle to me, frankly, why this business model hasn't yet emerged. Is it because server-based email and private conferencing (with NNTP or IMAP) aren't yet seen as essential business tools? Or because, as Dave Caplinger suggests, ISPs are stuck with the "POP3 mindset"? He defines that as the attitude that customers should connect, get their email the heck off the ISP's server, and disconnect." Drop by the newsgroup and let us know what you think about this.
Even when you manage to get roaming access to work, one way or another, there's one annoying limitation. As Dave Caplinger reminds us, newsgroup information isn't stored as part of the roaming profile.
I ran into this at my site, when we switched to standards-based email and conferencing from an older, proprietary system. Initially, I tried using the appropriate protocol and tool for the appropriate function, namely IMAP for email, LDAP for directory info, and NNTP for newsgroup/conferencing, with the intent of using Netscape Communicator with roaming profiles as the "universal client". The fact that newsgroup subscription information isn't kept as part of the user profile in Netscape became a problem, however.
Since my newsgroups were internal only and I was using Cyrus for the IMAP server, I was able to replace NNTP newsgroups with IMAP shared folders and get the same effect without needing to run INN at all any more. Another way to go was to mirror NNTP newsgroups into their own namespace in the Cyrus IMAP server, and I would have done this if I was getting any newsgroups fed to me from outside, but the downside is the duplication of articles in the NNTP spool and the IMAP "news" space, and the more complicated setup to keep the two synchronized. In my case, it made more sense to eliminate NNTP entirely, but your requirements could be different, of course. And if you have users that subscribe to multiple "boutique" news servers like news.cmpnet.com that provide their own newsgroups, then you can't even do this.
To the above setup I added IMP, a PHP-based "Webmail" application that provides an alternative method to access the same IMAP accounts and LDAP directory. It's accessible by anything on our internal network that can run a web browser with JavaScript support, and by anyplace on the Internet (via SSL) including customer sites, employees' homes, etc. with zero pre-configuration required.
The best part is that all of the tools to implement this are freely available and open-source! And the modular nature means you can replace pieces if you like; we switched out OpenLDAP in favor of Netsc.. er.. iPlanet Directory Server, for example.
Thanks, Dave, for that excellent overview! It's a wonderful illustration of the way in which Internet applications can be combined in seemingly endless ways. NNTP doesn't support roaming? OK, use IMAP. Although NNTP is the more obvious protocol for discussion, whereas IMAP is nominally an email protocol, the boundaries have blurred with the advent of IMAP public folders, which are shared mailboxes that can work almost exactly like NNTP newsgroups.
Your IMAP server doesn't support secure access via SSL (as is the case with the Cyrus product)? OK, use an HTTPS channel for that purpose. Dave's using IMP (the IMAP Web Mail Program) not only as a way to deliver mail into browsers, but as a way to leverage the SSL security that's more generally available in browsers and web servers than it is in mailers, newsreaders, mail servers, and news servers.
Responding to last week's column on Web charting, Jake Ochs noted:
Another efficient alternative for the problem you discuss in your most recent article is to use client sode javascript to generate a graph based upon coordinate data you supply on page load time. Read more here: http://developer.netscape.com/docs/technote/javascript/graph/index.html
Thanks Jake! Of course in my case I often (well, almost always) get the hairy eyeball when I propose the use of client-side JavaScript. And I guess I understand why people feel that way. But geez, can't we ever start just assuming that some basic subset of JavaScript exists and is useable?
Jake Ochs:
I'm surprised that in this day and age (why, its Y2K!) clients are still averse to JavaScript. Most of my development work is for intranet or extranet type development and it is a given that JavaScript is necessary to provide the sophistication that clients require of the applications I am charged with developing. I always set a baseline browser level when I start a project and work from there.
Frank Arnaud:
It's hard to think a use of Javascript or frames for ordinary public sites that adds more than zero value to a site. More often than not they seem just to be about making the site more user-hostile.
Fred Pacquier:
I'm not entirely sure about JS, but I certainly agree about frames. It especially galls me to see the incredible number of framed sites that reload the entire frameset each time whatever you do and wherever you click, thereby defeating whatever (feeble) justification might have existed in the first place, and painfully showing the lack of understanding of basic principles by the author(s). There certainly are valid, value-added uses of frames for certain interface problems, but in the real world examples are few and far between...
Alan Shutko:
The problem with frames is that they're a catch-22. If you reload the entire frameset each time, you hear complaints like this. If you don't, you hear complaints that people can't bookmark pages.
Peter Hess:
I really want to use CSS on our corporate website, mainly becasue it makes the site maintenance so much easier. But we've decided not to since we get about as many Netscape users as IE users hitting the site. Netscape support for even basic CSS-1 is atrocious. The pain of trying to gin up a single style sheet that works on both browsers is too much.
Ruta Duhon:
CSS in Netscape browsers starts a vicious cycle: Javascript must be enabled for CSS to work, but if a Javacripted ad kills the browser, people disable Javascript and that disables CSS.
Yikes! Little did we know, back in 1994, that the first-generation Web technology that was then taking hold would become such a powerful installed base that, five years later, we'd still be debating whether the time has come to deploy client-side JavaScript, frames, or CSS!