Internet e-mail was introduced as part of the recent DR8 release of the BeOS™. As a number of developers have pointed out, the DR8 version of the mail system broke a bit too easily when confronted with certain POP/SMTP servers. A new version that fixes these incompatibilities will be included as part of the update to DR8 (coming soon to an FTP site near you). In the mean time, this article explains the architecture of Be's mail system.

The mail implementation consists of three parts: The mail daemon, which sends and receives mail; the mail portions of the Network Kit, which provide interfaces for applications that want to create their own mail-reading and mail- authoring applications; and BeMail, which is a simple application for viewing and authoring mail messages.

The mail daemon is a background application, which checks for and sends mail according to a schedule that the user can configure through the E-Mail preferences application. The daemon gathers new pieces of mail from the server and stores each as a record in the Be database. Fields that are defined in the "E-mail" database table (see headers/net/E-mail.h for the table description) are scanned for in the message and added to the record. The message header and content are stored unmodified in their entirety in this record as well. If the message contains MIME enclosures, the enclosures are extracted and saved into the /boot/Enclosures directory; references to the enclosures are also added to the database record. Enclosures encoded using base 64 are decoded automatically.

Using the database to store mail allows the user to sort mail in a number of ways using queries. For instance, I can set up a Browser query to show me all mail sent to me from Jean-Louis by using the Browser's Find Panel and specifying "Name contains JLG"; to view only the mail that has arrived since yesterday, I can create a query with the Find Panel and specify "When since yesterday." (Hint: Open the Queries icon in the dock to sees all queries that have been made. You can rename and drag these queries to the dock for quick reference.)

For developers who want to add e-mail capabilities to their applications, the Network Kit's BMailMessage provides an interface to the "E-mail" table, and to the mail daemon's message-sending functions. An example for an application that does automatic registration is as follows:

#define COMPANY "reg@be.com"
#define SUBJECT "registration"

void register(user, id)
{
   BMailMessage* mail;

   mail = new BMailMessage();  // construct mail object
   mail->AddField(B_MAIL_TO, COMPANY, strlen(COMPANY));
   mail->AddField(B_MAIL_SUBJECT, SUBJECT, strlen(SUBJECT));
   mail->AddField(B_MAIL_CONTENT, user, strlen(user));
   mail->AddField(B_MAIL_CONTENT, id, strlen(id), TRUE);
   mail->Send();
   delete mail;
}

This constructs a new BMailMessage, adds three fields to the message (the TRUE for the second B_MAIL_CONTENT AddField is a flag to append the new data to the existing data for this field type), and queues the message to be sent the next time the mail daemon is scheduled. The message will be removed from the database after it has been sent successfully. Options to Send include sending the message immediately and saving the message after being sent.

Note: The only requirement for sending mail is that there be a recipient. This means the message must have a B_MAIL_TO, B_MAIL_CC, or B_MAIL_BCC field.

The last part of the e-mail package is the mail reader (users can pick the reader they prefer with the E-mail preferences application). With DR8, we ship a simple application, called BeMail, which reads, replies to, forwards, and constructs e-mail. For developers who want to create more interesting mail readers, the only requirement is that they assign the document type 'mail' to their application's APPI resource.

To help simplify the process of writing more interesting mail readers, we're making the source for BeMail available on the FTP site. BeMail is a fairly complete BeApplication. It has examples of database access, threading, messaging, multiple views, and includes classes from a number of different kits.

The source is broken down as follows:

The size of the object is greater than 64K so you won't be able to build it with the version of CodeWarrior that ships with the BeOS (you'll need to buy the unlimited version from Metrowerks).

I haven't commented the source code particularly well, but according to the MS Word grammar-checker, it's written at the eigth-grade level, so you shouldn't have too much trouble going through it.

So, two weeks on the job so far and things are looking up. Like so many new employees, I wanted to hit the ground running. Bright eyed and bushy tailed. The world is a nail, and I have a big hammer!

From the outside looking in, I didn't realize how much enthusiasm there really is in the Be community. But it's not just enthusiasm, there are a boat load of truly good-looking applications in the works, or already on our door steps. I would like to share some of the gems that show up at the ftp.be.com site, just in case you haven't already noticed. Caveats about favoritism, and objectivity aside, I think these are really cool and needed applications.

Title: Audio Elements
Location: ftp.be.com/pub/contrib/audio/ae10.tgz
Author: Attila Mezei (amezei@m18.datanet.hu)

If you haven't had a look at this yet, it's a definite must see. Basically, you have the ability to graphically layout what are known as audio networks. That is, you can hook up things like a microphone to a speaker by drawing a line between their graphical representations. That's about the simplest operation you can do. You can add filters of all sorts and mangle your sound in a million different ways. And get this... add-ons are an integral part of its architecture. Creating your own add-ons is relatively easy. You kick start the process by selecting from a menu, filling in a little bit of information, and generating a stub. Now you're left to actually write the code to do whatever it is you want.

There's just too much in this little (currently free) package to mention. All I can say is, if you're interested in fiddling about with audio on the BeBox, then give this thing a try.

Title: Kftp
Location: ftp.be.com/pub/contrib/network/Kftp-2b1.tgz
Author: Laurent Pontier (pontier@efrei.fr)

The BeOS ships with a standard command-line version of the ftp client. This is good enough for UNIX hacks who may not be exposed to anything much more elegant, but Windows and Mac users will be much more satisfied with something that has a nice graphical user interface. Kftp is such a program. It presents a nice GUI ftp client. Transferring files is a matter of click, click, that's it.

Titles: Viewer, Rotator, Sphere, Gouraud
Location: ftp.be.com/pub/contrib/gfx/demos, viewers
Author: Tinic Urou

These are little graphic applettes. They typically perform a single function, and they all have the same general structure. But boy is this author (and associates) prolific! They all include informative source code (although not commented). Play with a couple of these and you might think, "I didn't know I could do that." I find these truly inspirational, and every time I run them I get giddy and want to stay up until the wee hours of the morning trying to do something better. You'll find in them ways of manipulating a BBitmap directly and using messaging to run a loop without using Pulse().

SOME HINTS

Be provides the ftp.be.com site as a convenience to the Be community. It provides a central location for developers to share their wares. The site provides this convenience, but has some low-level maintenance associated with it. The maintenance is primarily provided by the users that take advantage it, but we also do some work.

On a daily basis we download all the things that are in the incoming directory and put them onto a BeBox. Then we unpackage and run each one. This is to ensure that we aren't posting pornography and that we can gunzip the packages run them on most machines. Then we make an entry in the whatsnew file so that people can see what's come in lately. If it can be run, then we move it over to the contrib area. We do not perform any virus checks, or check for maliciousness, so you should be aware of this when running an executable that doesn't supply source code. Use at your own risk.

When you post something to the ftp.be.com site, you should fill out the Developer Support form in the Registered Developers Area. That way we at least know that it's there. Even though we look every day, some things come in that we don't have the ability to gunzip due to corruption, so they stay in place because we don't know who sent it. Also, feel free to add an entry for it to the BeWare section of the web site. The form to do so is available in the Registered Developer Area.

When posting, include both a .tgz file and a .readme file. That way everyone knows at a glance what the package includes without having to download it.

LAST THOUGHTS

Spreading excitement is relatively easy to do on this platform. There is so much fuel for the fire that all I have to do is point in the right direction and jump up and down. But it still remains the case that developers need some hard questions answered, and not just cheerleading. Most of the time, good developers just need to be sent in the right direction to find out how to best utilize the BeOS.

This week's tutorial focus is the source code for the BeMail client. You'll find the package at:

ftp.be.com/pub/Samples/BeMail.tgz

This is the source code straight from Robert Polic, who wrote it. The only change is that the code has been commented in some areas to explain what's going on. It's all pretty straightforward and should be beneficial to anyone looking how to do mail, access the database, do messaging, use menus, and generally use a lot of GUI stuff.

Creating these tutorials is an evolutionary process. This code release is typical of a first pass, the code is commented. Like the Gamestick tutorial last week, more information will be available later. Speaking of which, the Gamestick tutorial actually has a tutorial now. More explanation of what is actually going on and how to use the code effectively.

Enough said.

OK, so I'm sitting in this room full of people I don't know. I'm staring at a monitor hooked up to this gaudy looking oversized lego building block, and all I can think is, "The application he closed just crashed. It must have crashed... It went away too quickly." There was no "please wait while the application shuts down," no hourglass spinning around and around, ad nauseum—just *POOF*. No app.

I know, it seems like a small triviality, but the speed really impressed me. So much that I formed BitBrothers to code on it, and teamed up with Janine Terrano, a wonderful marketing magician and visionary. Together we hope to produce applications under the name Matrix Softworks, Inc. My brother just bought his box last week instead of his first choice, a Power Computing machine. I had nothing to do with it. Really, I swear.

Well, it's a few months later, the bevel on the front of the machine we bought is a bit toned down from the original (nice neutral gray), but the snap-off thingies sitting atop the bevel are still an enigma to me. A friend mentioned that they may snap off so you can stack BeBoxes on top of each other. Legos again. Go figure.

Thinking about it twice, I suppose that even if the case isn't supposed to be a lego, the operating system certainly reminds me of one. Want a window? Sure, just make one. No hidden agendas like "you have to set X and make sure a function handle in Y is set to Z." Building apps on the BeBox reminds me of those plastic models I use to build in high school, only you don't have to follow the instructions, you don't need glue, and the parts talk to each other.

It was precisely my endeavors in learning this new API that lead to the idea of creating Pixel Magic, a paint program that will hopefully see the light of day early next year.

At first I wasn't so sure I should do it. I mean, come on, a PAINT program? Everyone and his evil stepmother's twin was probably working on one. Why should I? Or, perhaps that's what everyone else was thinking. So maybe I should do it.

So I am.

I don't want to give too much away before Christmas (that wouldn't be much fun, would it?), so let me mention a few phrases describing PM that you can subliminalize: Independent layer animation plug-in filters tools alpha datatypes multiple undo cool awesome neat. You'll see more at the January show, I'm sure.

As for other products on the horizon, I'm itching to put out a really fast 3D two-player heart-pounding adrenaline- coming-out-of-your-ears game, perhaps based on the 3D Kit. I've gotten pretty far on it already. You run the application and a tilted 3D box appears on a black background. Okay, so I've got some work to do...

Anyway, Be's support has been exemplary. Well, almost. I'm still confused as to whether or not CopyBits() is buggy or if it's my code. Dominic? The ubiquitous bug list idea comes into mind. Idea: Put a developer-editable and repliable bug list in the developer's area of the web site. Allaire (http://www.allaire.com) has something like this and it works wonders. Other than that, I'm not too critical about the state of the BeBox and its software. I applaud Be for not going Microsoft on their products. I plan to follow suit and release PM as an infant application. I figure at the very least it will give me more time to spelunk around the insides of the machine.

The short answer is no. Not exactly, not today. But, for a while, PCs have been encroaching on traditional workstation applications. Windows NT, with an effective combination of publicity and reality, has made the invasion more obvious. But it started long ago and, as a result of the age of the subject, it's surrounded with a good amount of folklore.

For the longest of times, workstation makers and users have wondered at the proliferation of PCs. How could people use these? They don't even have a real operating system, their networking is primitive, they're slow as molasses, with ridiculously small memories and screens. And yes, PCs were primitive when compared to UNIX workstations. The PCs had other advantages, such as being affordable, friendlier—meaning useable by a much larger constituency. Just as important, their hardware and software were more standardized, meaning more individuals and companies would invest to develop programs and add-ons for them. But UNIX- based workstations reigned in server and technical applications, such as computer-aided design and software engineering.

Over time, seeing the success of PCs, workstation companies tried various approaches to what is, from their perspective, the low end—desktop publishing and other office automation applications. They never scored any notable success. Sun executives used to be irritated at the number of Macs in their offices; they were used to make those lovely overheads for their meetings. Silicon Graphics tried several times to capture the high end of multimedia PC applications and, so far (they're trying again), failed to make any money at it.

There are two likely factors to this persistent lack of success. The first is the fact that software, and more generally computer architectures, just don't scale down. Software poured into a smaller vessel than the one it was designed for doesn't work very well. The other factor is the babelization of the UNIX world. Workstations sold in much smaller numbers than PCs, less than a tenth, and hardware and software were very fragmented, thus making third-party investments less attractive. PCs, on the other hand, were becoming more powerful and started attracting CAD/CAE software. I remember, when we started Be, we picked inexpensive 486 PCs to do logic design and to route motherboards. DOS wasn't a pretty operating system, but it loaded the application and got out of the way. And if the motherboard routing wasn't always very fast, it got done anyway and got done very cheaply.

With Windows NT, one of the objections to PCs in some demanding applications disappears. Windows NT is a real operating system, big, brawny, likes lots of hardware, complicated—but real. Monitors, graphics accelerators, memory, and network connections are on par with workstations—only less expensive.

Does this mean Sun, Silicon Graphics, HP, and Digital should cry uncle and give in to the combined might of Intel and Windows NT? Of course not. Silicon Graphics, for instance, is shooting for the high end. They bought Cray Research and have a very prosperous business of multiprocessor servers and virtual-reality engines. These high-end machines are now used in TV broadcasts to make a virtual studio around an anchor standing or sitting against a blue background.

The next development to watch will be Intel's efforts to re- architect PCs. Today's processors are already poorly served by current memory and I/O systems. The basic PC/AT design goes back to 1984. We should see the PC organ bank we're so fond of get much better components with the arrival of Intel's next generation of processors.

And what about us, Be, in this PC vs. workstation border conflict? Border is the right word. We'd like to be as friendly and affordable as a good personal computer. And, with the BeOS, we hope to provide the brains and the muscle of a workstation, with an agile OS optimized for demanding, high-bandwidth digital media applications. Someone even called us the poor man's Silicon Graphics.

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.

To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.