TidBITS#352/04-Nov-96 ===================== Have you heard the latest about Apple and Be? If not, there's enough rumor and innuendo to put soap operas to shame! Also this week, news on the OpenDoc-savvy Nisus Writer 5.0 and a new extension from Apple for Power Macs running System 7.5.5. Plus, Bungie Software founder Alex Seropian exposes the seedy, cash- driven world of commercial software distribution, and Adam takes a comprehensive look at Mac email directory services... or the lack thereof. Topics: MailBITS/04-Nov-96 Heads Be Spinning Nisus Writer Turns 5 Distribution Myths and Lies Directory Services on the Mac Copyright 1996 TidBITS Electronic Publishing. All rights reserved. Information: Comments: --------------------------------------------------------------- This issue of TidBITS sponsored in part by: * APS Technologies -- 800/443-4199 -- Makers of hard drives, tape drives, and neat SCSI accessories. APS price lists: * Northwest Nexus -- 800/539-3505 -- Professional Internet Services. * Power Computing -- 800/375-7693 -- PowerTower Pro 225 MHz - the fastest desktop system ever. Build Your Own Box online! * America Online -- 800/827-6364 -- The world's largest provider of online services. Give Back to the Net! * EarthLink Network -- 800/395-8425 -- Providers of direct Internet access for Macintosh users. For eWorld refugees: no setup fee! * Aladdin Systems -- 408/761-6200 -- Makers of StuffIt Deluxe 4.0, the Mac compression standard, and InstallerMaker 3.1.1, the leading installer for Mac developers. --------------------------------------------------------------- MailBITS/04-Nov-96 ------------------ **PowerPC Interrupt Extension** -- If you've been seeing inexplicable hangs or momentary freezes on your Power Mac, Apple might have an answer for you in the new PowerPC Interrupt Extension. Drop this in your System Folder, and it fixes one known cause of "long interrupt latencies" - basically, where the computer sits around waiting for something more important to happen. It's difficult to say what specific problems this extension will fix since so many programs can be affected, but reports indicate the extensions fixes formerly-reproducible problems with some games, telecommunications software (including PPP), and audio/video editing tools. This extension _requires_ a Power Macintosh and System 7.5.5. [GD] **SuperCard 3.0 Announced** -- Allegiant Technologies has announced SuperCard 3.0, which it expects to begin shipping this month. This latest version of the multimedia authoring tool features new authoring and project-level tools, new comprehensive documentation, and integrated Internet support for development to Allegiant's Roadster Web browser plug-in, plus integrated support for URLs and common online file formats. SuperCard 3.0 will have an estimated price of $329, with $99 upgrades for users of previous versions. [GD] Heads Be Spinning ----------------- by Geoff Duncan Nature abhors a vacuum; apparently, the same is true for the mainstream and trade press following Apple's operating system plans (see TidBITS-343_). Last week brought a new torrent of speculation from Reuters and MacWEEK about Apple Computer, newcomer Be, Inc., and the future of the Mac OS. All told, these articles hinted at a brand new Macintosh operating system that might run on Intel-based machines, an Apple buy-out of Be, and a hybrid Copland-Be system that might be ready by mid-1997. Add to these articles hundreds of increasingly spurious rumors and threads on the Internet, and the lines between fact and fallacy nearly vanish, so far as the general public is concerned. Both Apple and Be have issued "clarifications" to refute statements in these articles. Apple denies it has signalled a new direction in its OS strategy, or that it's planning a version of Mac OS written from scratch that would also run on Intel processors. Be Director Mark Gonzales has specifically disassociated his company from a report in MacWEEK's Mac The Knife stating Apple wants to acquire the Be OS at least partially to leverage revenue as a BeOS developer and as a publisher of other BeOS products. Gonzales states flatly that Be is not open to business alliances along those lines. However, as with Apple's recent attempts to elucidate its operating system plans, these official responses have generated more questions than answers - what Apple says is overshadowed by what Apple is _not_ saying. Apple has not denied it is in acquisition talks with Be; similarly, Apple has not denied it is considering a hybrid operating system built on Copland's microkernel with Be's application layer. Add to this a story in today's San Francisco Chronicle that Apple is actively seeking to locate (and possibly fire) employees who are sources of recent news leaks and rumors, and you get what can only be described as an untenable public relations position. So far, Apple's most definitive statement regarding its operating system plans is that it plans to make a definitive statement in "early 1997." Unfortunately, if rumors continue as they have been, that stance will only make a bad situation worse. At this point, it's too murky to tell what the final outcome of this windbaggery might be. However, Apple and Be have reasons to talk to each other that have little to do with Apple acquiring Be's operating system. Be may have a significant interest in Apple's "middleware" (like QuickTime and QuickDraw 3D), and Apple should want to see Be's port of Be OS for the Power Macintosh succeed, whether or not it's under an Apple logo. In the meantime, Be is pushing ahead with a developer release of BeOS for Power Macintosh (to be bundled free of charge with the January issue of MacTech magazine), and technical discussions are appearing about the realistic possibilities of the Be OS on Macs. We can only hope both Apple and Be understand silence only encourages unwarranted speculations and that they should take control of the situation, rather than letting the situation control them. Nisus Writer Turns 5 -------------------- by Tonya Engst Starting this week, Nisus Software plans to begin shipping Nisus Writer 5.0, the latest version of its word processing application. Although there's a bevy of major improvements to the feature set and interface, Nisus Writer's primary claim to fame is that its Power Mac version is among the first applications to act as an OpenDoc container. Nisus Writer also scores a first with its support of drag & drop for non-contiguous selections. The new version supports numerous Macintosh standards, including Internet Config, Apple Guide, AppleScript (Do Script and a modest Nisus Writer suite), robust drag & drop, Macintosh Easy Open, QuickDraw GX printing, and the Word Services suite for third-party utilities like spelling and grammar checkers. I'm particularly looking forward to checking out the changes in the HTML capabilities of the new version. In addition, non-Roman language users of Nisus (except for folks using the Hebrew version or the Hebrew Mac OS) will appreciate the new version's lack of a dongle requirement. Termed a "language key" by Nisus Writer, the dongle is a specialized device that plugs into the ADB bus. Without a dongle, Nisus Writer operates in a limited demo mode (see TidBITS-170_). Nisus Software recommends a 68020 or higher Macintosh running System 7.0 or later, though some features require a later version of the System. For the 68K version you'll need 4 MB of application memory, and for the Power Mac version, you'll need 2100K of application memory with virtual memory or RAM Doubler on, 5100K without. Upgrades cost $89 if you want a printed manual; $69 if you use an Acrobat version of the manual. There's also a $10 discount if you upgrade by 22-Nov-96. Nisus Software -- 800/890-3030 -- 619/481-1477 619/481-6154 (fax) -- Distribution Myths and Lies --------------------------- by Alexander Seropian When I started Bungie Software, all I wanted to do was write a computer game and sell it, just like I sold popsicles during the summer when I was in fifth grade or my chemistry notes in college. My naive vision had an elegant simplicity, a kind of commercial innocence. It wasn't long before that innocence was betrayed by the long list of vendors, distributors, retailers, and mail order companies who were more than eager to insert their grubby hands into my pie. Now, don't get me wrong: we couldn't have made it to where we are, or get where we're going without these channel partners. But there's a lot that goes on behind the shelves that consumers seldom realize. Bungie sells to several different kinds of customers. We sell direct to the end user, we sell to mail order companies (from whom consumers buy), and we sell to large distributors (that in turn resell to stores, from whom consumers buy). Selling directly to the end user is a simple process, but retail distribution gets more complicated. **Channel 1: End User Sales (easy)** A) Bungie places an ad. B) Customer sees the ad and buys the product. C) Bungie ships the product to the customer. Here, step A can be a magazine ad, direct mailing, newsletter, Web site, demo, etc. **Channel 2: Mail Order (harder)** A) Bungie submits a product to Mail Order Company for evaluation. If approved, Bungie doesn't ever have to do this again. (This didn't happen until we released Pathways Into Darkness for most of the mail order companies.) B) Bungie buys an ad. That's right, Bungie doesn't sell a product to the mail order companies. The mail order companies have sales people, whose job it is to sell ads to Bungie (the sales people get commissions, too). The tricky part here is that Bungie must buy the ad two to three months before the ad comes out, so a December catalog is booked in October. As you know, planning for new products can be hard, and mail order companies, by law, are required to estimate shipping dates, which is why they frequently say "two weeks" even when Bungie is saying "we don't know." C) Mail Order Company sends Bungie an order for product. This absolutely doesn't happen until Step B is done. D) Customer sees the ad and buys the product from Mail Order Company. E) If Mail Order Company bought too much, then they send the product back. That's right, nobody actually buys product from Bungie! It's all consignment. If Mail Order Company doesn't sell it, the product comes back to Bungie. Remember this lesson, it repeats later. Special Notes: With entertainment software, a mail order company derives most of its profit from the advertising sales, not the product sales. A full-page ad in one of the big Mac catalogs costs about $25,000 (multiply that by 150 pages for some big monthly numbers!). On a given month, Bungie may pay $9,000 for an ad. For the mail order company to make more than that ad price they would have to sell over 1,200 units of product that month, which only happens around Christmas. Consider MicroWarehouse, a publicly traded company that does around $750 million in business per year. They produce four catalogs with a total of over 600 ad pages a month. This generates a mammoth $180 million per year. The remaining revenue ($570 million) is generated by product sales and yields only a 20 percent margin. That puts the net revenue at $180 million for ad sales and $114 million for product sales. Remember this lesson, it repeats later. **Channel 3: Retail Distribution (extra hard)** A) Bungie submits a product to a distributor for evaluation. The distributor says, "Bungie who?" B) Bungie spends years and lots of money trying to make a name for itself so Bungie can go back to the distributor with an established customer base. C) Repeat steps A and B as long as necessary. D) Distributor finally offers Bungie a contract with the following options: * Bungie guarantees that the distributor is getting a better price than anyone in the world. * Bungie agrees to take back any product the distributor fails to sell. (Remember the consignment lesson.) * Bungie agrees to give the distributor anywhere from 3 to 6 percent of sales as a marketing fee. Distributors typically mark up software by 1 to 3 percent; think back to the lesson on how marketing profits outweigh product profits. * Bungie agrees to spend at least $10,000 on product launch marketing with the distributor. Again, remember the marketing profit lesson. * Bungie agrees to pay shipping to the distributor. * Distributor agrees to pay Bungie 30 to 90 days after delivery of product. This is the biggest joke here. Distributors _never_ pay until they need more product. E) Bungie tries to negotiate, but ends up getting the shaft like the rest of the software developers and signs the contract. F) Distributor says, "OK, to place your products into Retail Store X, you must spend $5,000 on their in-store catalog." Or even better, "You must pay $25,000 on their end-cap." (An end-cap is a product display positioned prominently at the end of an aisle.) That's right, kids (this is another important lesson): every time you walk into a store and see 100 copies of Mutant Death Machine stacked at the end of the aisle, it isn't because the store thinks the game rocks. It's because the publisher paid big bucks to place it there. And the store keeps those big bucks as profit. G) Bungie sells some product to the distributor. H) Now Bungie realizes that to compete with all the other software that the distributor sells, we have to bribe the sales people. It's called a _spiff_. That's when Bungie says, "OK, I'll give you a dollar for every unit you sell to a store." Alternately, we have to tell the distributor that we'll give them a rebate of 5 percent if they sell a certain amount. I) OK, here's the best part: The distributor goes out of business owing Bungie a ton of money. Now, this whole rant may sound like a bunch of whining from a company that's made plenty of moolah selling a great game, and it is whining. But, wouldn't it be nice if selling software were like selling popsicles on a hot summer day? [Alexander Seropian is CEO and Founder of Bungie Software and is constantly evolving his job role by hiring talented people to work with. Eventually there will be enough smart people around that he'll be able to sit around all day and do nothing.] Directory Services on the Mac ----------------------------- by Adam C. Engst A while back I wrote an article about the lack of directory services on the Macintosh for MacWEEK, and as is often the case with paper publications, felt that I couldn't fit all the information I had into the article. So, here's another take on the subject from a rather different point of view. It all started when I asked my editor at MacWEEK if I could write about using Internet email servers in an intranet situation. I find intranets quite amusing, since their entire point is that they use standard Internet protocols and software, and yet somehow they're big news in the trade publications. Nonetheless, email is one of my favorite topics, and since we run a large mailing list with TidBITS, we have an intimate knowledge of the limitations of most LAN email packages gatewayed onto the Internet. In many situations where an office has an Internet connection, it's easier, cheaper, and friendlier to run a real SMTP/POP server than something like QuickMail, cc:Mail, or FirstClass. There are a number of complete SMTP/POP servers for the Mac now, ranging from the free Apple Internet Mail Server (AIMS) to Stalker Software's Swiss Army knife of email servers, CommuniGate, to Sonic Systems' SonicMail. For offices not already connected to the Internet, Claris's OfficeMail speaks SMTP and POP to email clients like Eudora and Emailer, and UUCP to get out to the Internet (see TidBITS-336_). There's also a new Mac SMTP/POP mail server called RingTwice in beta testing, but it too seems to lack directory services features. Add all this to Tenon Intersystem's plans to bring out an industrial-strength mail server based on Post.Office, and you have a wide range of choices. However, because I don't work in a large organization, there's a problem I hadn't anticipated when I wrote that article: directory services. How can you look up the email address of someone else in your large organization? I was a surprised by the number of comments about this topic, because I always considered the Internet to be my "large organization," and on the Internet there's no guaranteed way to look up email addresses. (There are attempts of varying success; the links under Finding People on the home page for Internet Starter Kit for Macintosh take you to most of them). Let's assume that everyone in a large organization lives and dies by the address book in their LAN email program. I haven't run QuickMail since 1989, and I've never seen cc:Mail in person, but it seems unlikely all of these address books contain much more than fields for name and email address. What if an address book feature lacks a phone field, a fax field, or a snail mail address field? And who's in charge of getting and filling in all that information for local people? I'm sure organizations try to handle the issue - one person who has worked at several large publications said that they always tried to keep an organization- wide contact database in Now Contact or something similar, but these databases always fell prey to incorrect data and other problems. In other words, it's my suspicion that existing solutions in LAN email packages don't always solve the entire problem. **Existing Solutions** -- That said, how can we solve this problem of a lack of directory services for current Internet email servers? There are plenty of possibilities, some of which depend on which email server you use and which email client you use. The problem breaks down into roughly three parts: dealing with the information at the server, manipulating the information in the middle, and searching it on the client. Of the Mac Internet email servers, only CommuniGate has address book functionality built in (although it's only accessible with the CommuniGator client software), and you can export the address book of local users to a tab-delimited text file. That's not possible in SonicMail or Claris OfficeMail at all, and is only possible for AIMS with the freeware MailShare Loader, available only at the URL below. If you create users in either AIMS or CommuniGate, exporting a list to a tab-delimited text file offers a variety of options. My inclination would be to import it into either a custom database in something like FileMaker Pro or into Now Contact. You might have to do some work to set up the import filters (or even manipulate the text file first). Once you have your users in a database, you can add fields not supported by the email server, sort the list in a variety of ways, and of course, export it to a variety of formats. One possibility is simply to make the database accessible to everyone in the company. That might prove financially difficult if it involved a site license for a contact database, although a FileMaker Pro database could be used as a runtime. Both FileMaker Pro and Now Contact are sufficiently scriptable that someone could write a script to send email via a scriptable email client like Eudora. I'm not a fan of brittle scripting solutions, though, and I'd consider this an interim hack. I'm more in favor of exporting the user list from the database into a couple possible formats. If you have a site license for Eudora Pro 3.0, you could export to a Eudora nicknames file, put it on a central server, and copy an alias of it into each user's Nicknames Folder in their Eudora Folder. Eudora Pro 3.0 handles these nickname file aliases perfectly, although you might want to lock the original to prevent unauthorized changes. So, if you use Eudora Pro, this suddenly gives you an organization-wide address book, complete with phone numbers and snail mail addresses. This technique doesn't work with Eudora Light, which only supports a single Eudora Nicknames file. Alternately, how about exporting to a Web page? HTML is sufficiently simple that it isn't difficult turn an exported text file into HTML with a Nisus Writer macro or another text tool. Take the entire concept one step further with a CGI like Tango, WEBFM, ROFM, or Lasso, and you could link your database directly to your intranet or the Web. And, lest I be accused of forgetting too many possibilities, there are a number of Web servers built on databases that might be able to do this stuff in their sleep. Possibilities include Web Server 4D, NetWings, and Webink. Making the information available on a Web page is great, but predisposew people to using the mediocre email clients in most Web browsers. If you like Netscape Navigator's email client, fine, but you can set up Navigator so mailto links are passed off to a different program. Just copy this tiny AppleScript into Script Editor, change it so it matches the name of your copy of Netscape and the creator code of your email program (if not Eudora, as shown below), and run it. To be honest, I'm not sure which other email programs can work with Navigator in this way, although betas of Eudora Light 3.0.1 appear to do so. tell application "Netscape Navigator 3.0" register protocol "CSOm" for protocol "mailto:" end tell Without getting into the nuances of scripting Web browsers, this technique should work with Microsoft Internet Explorer and Spyglass Mosaic, though you may need to run the script each time you launch the browser. If you need to restore your browser's default behavior, change "CSOm" to the creator code for your browser ("MOSS", in Netscape's case) and run the script again. If you use Eudora Light 1.5.4, you can set the script to use the Eudora GURL Helper application that comes with Internet Config instead of Eudora Light itself. Finally, although it lacks elegance and integration with email programs other than Eudora, there's always the Finger protocol. Finger has been around for a long time and can be used to make directory services information available. There are a couple of Finger servers (such as FingerToys from Acme Technologies and Peter Lewis's Daemon) and Finger clients (including Peter's Finger and a Finger HyperCard stack, not to mention Eudora Light and Pro), but I haven't heard of many people utilizing Finger to solve directory services problems, which leads me to believe it's not really a viable solution. **Future Solutions** -- These hacks are fun to invent, but they aren't the best way to solve the directory services problem. For that, I believe we need support for a directory services protocol in Mac email servers or a link with a generalized directory services server. One possibility is the Ph protocol Eudora author Steve Dorner developed. It's a simple, text-based protocol that provides a sufficient amount of information and already has some support in Eudora and in John Norstad's free Mac Ph client. No one has yet developed a Ph server (properly called a qi server) for the Mac, which has proven an obstacle to further acceptance of Ph. Rumor has it Ph support will be forthcoming in a future version of CommuniGate and in AIMS 2.0, so perhaps Ph will enjoy a resurgence. As attractive as Ph might be, thanks to its ease of implementation and text-based nature, a different protocol has the backing of most big companies. LDAP, or Lightweight Directory Access Protocol, started life at the University of Michigan as a subset of the X.500 directory access protocol. LDAP developer Tim Howes and two others at the University of Michigan who worked on the project now work at Netscape Communications. Needless to say, Netscape is in favor of LDAP, and numerous other large companies have signed on as well. Mac client support for LDAP comes in the form of a program from the University of Michigan called maX.500, although Gavin Eadie is also working there on a Live Object LDAP browser for Cyberdog. These programs sort of solve the client-side issue, but for a directory services protocol to gain wide acceptance it must be integrated into all the primary email clients. LDAP is more complex than a simple text-based protocol like Ph, which makes supporting it in an email program more difficult. In classic fashion, Steve Dorner noted, "This overwhelming complexity is one of the reasons that X.400 and X.500 have lost the battle, and the Internet has won. LDAP is corporate revenge." Corporate revenge on programmers LDAP may be, but without support from all the main Mac email clients and some Mac LDAP servers (which haven't yet reared their heads), it's hard to see how LDAP could make significant inroads into the Macintosh world. With sufficient support, it could be the solution so many people are waiting for; until then, Godot could arrive first. **Pie in the Sky Solutions** -- The ideal solution to this problem is to have directory services built into the Mac OS. In fact, the much-maligned PowerTalk had some of those capabilities. It's ironic - PowerTalk was a flop as an email handling technology because Apple ignored most of the email world while PowerTalk was in development. PowerTalk also suffered from interface and architecture oddities, but I've had a number of conversations lately that ended in "Of course, PowerTalk did that." PowerTalk had an OS-level database of sorts, supported OS-level directory services, and had keychain functionality that simplified maintaining numerous userids and passwords for servers. Those technologies - along with the PowerTalk replacement for the embarrassing Chooser - would be welcome today, if only they hadn't carried significant overhead and the baggage of a barely usable email client. When Apple discontinued PowerTalk, I remember talk of how the technology wouldn't disappear entirely, but would be broken up and implemented differently in a future version of the Mac OS. Perhaps we can look forward to some of these technologies appearing in future releases of the Mac OS - whatever those may be. $$ Non-profit, non-commercial publications may reprint articles if full credit is given. Others please contact us. We don't guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. This file is formatted as setext. For more information send email to . A file will be returned shortly. For information on TidBITS: how to subscribe, where to find back issues, and other useful stuff, send email to: Send comments and editorial submissions to: Issues available at: ftp://ftp.tidbits.com/pub/tidbits/issues/ And: http://www.tidbits.com/tb-issues/ To search back issues with WAIS, use this URL via a Web browser: http://wais.sensei.com.au/macarc/tidbits/searchtidbits.html -------------------------------------------------------------------