The Node Monitor is a new service that will accompany the DR9 file system. It lets your application ask to be notified when certain changes are made to a file or directory. For example, you can "watch for" the creation and deletion of files within a directory, for the modification of a specific file's attributes or name, and so on.

As a built-in feature of the file system, the Node Monitor is part of the kernel: It's always there. However, it's anticipated that most applications won't need the Node Monitor; watching the state of the file system is important to servers and to navigational applications like the Tracker, but your Tetris killer—or even your Excel insulter -- probably isn't going to care.

The Node Monitor is, in our estimation, an advanced feature; the API for the Monitor is, suitably, rather low level—it's not downright unfriendly, but it does have a somewhat more mechanical view of the identity of files, as we're about to see.

CAVEAT: The API that we'll be looking at throughout this article isn't set in stone. Although the general concepts should remain valid, some of the names may change before DR9 is released.

To tell the Node Monitor that you want to watch for changes, you use the global watch_for() function:

watch_for(ulong flags, dev_t device, ino_t inode,
  constBHandler *handler, constBLooper *looper);

The file or directory (or "node") that you're watching is represented by the combination of the function's device and inode arguments. (Conversion between device/inode and the entry_ref structure/C++ objects, which were described in last week's Newsletter, will be provided by the Storage Kit.)

The activities that you're interested in watching are represented by the constants that you pass through the flags argument:

• B_WATCH_NAME means you want to be told whenever the node is renamed. This includes being moved to a new directory.

• B_WATCH_STAT watches for changes to the stat structure. This is the structure that records a node's size, creation and modification dates, permissions, and so on.

• B_WATCH_ATTR watches for changes to the node's attributes. (See Be Newsletter #51 for more on attributes.)

• B_WATCH_DIRECTORY watches for any changes to the list of files that a directory contains. In other words, it watches for files that are added to or removed from the directory. Obviously, this flag only applies to directory nodes.

The special flag B_STOP_WATCHING can be passed to stop watching the node.

When a change is detected, the Node Monitor generates a BMessage and sends it to the "watcher" (a BHandler object) that's specified in the watch_for() call. The watcher receives the message in its MessageReceived() function. (The Node Monitor divines the target from the handler and looper arguments through a series of logical steps that are really not very interesting.)

Each of the watched-for flags corresponds to a particular type of message: B_WATCH_NAME generates a B_ENTRY_MOVED message, B_WATCH_STAT generates B_STAT_CHANGED, and so on. We'll look at an example of the Monitor's messaging later in this article.

PrintServer::PrintServer() : BApplication('PRNT')
{
  dev_t spoolDevice;
  ino_t spoolInode;

  // Get the device and inode of the spool directory
  get_inode_for_path("/boot/system/spool", &spoolDevice, &spoolInode);

  // Start watching for new files in that directory.
  // The final two arguments tell the Monitor to send
  // notifications to this object's preferred handler.
  watch_for(B_WATCH_DIRECTORY, spoolDevice, spoolInode, NULL, this);

  // We're also going to need another looper later.
  fStatusWatcher = new StatusWatcher();
  ...
}

long PrintServer::MessageReceived(BMessage *msg)
{
  dev_t fileDevice;
    ino_t fileInode;

  switch (msg->what) {
  . . .

  case B_FS_NOTIFICATION:
    switch(msg->FindLong("opcode")) {

    case B_ENTRY_CREATED:
      // Get the device and inode for the file;
      // these are stored in the message.
      fileDevice = msg->FindLong("device");
      fileInode = msg->FindLong("node");

      watch_for(B_WATCH_ATTR, fileDevice, fileInode, NULL, fStatusWatcher);
      . . .
    }
  }
}

long StatusWacher::MessageReceived(BMessage *msg)
{
  dev_t fileDevice;
  ino_t fileInode;
  BFile spoolFile;
  char buf[16];

  switch (msg->what) {
  case B_FS_NOTIFICATION:
    switch(msg->FindLong("opcode")) {

    case B_ATTR_CHANGED:
      // make sure this is the status attribute
      // that has changed.
      if (strcmp(msg->FindString("attr"), "status") != 0)
        break;

      // Again, convert the msg into a
      // device/inode and thence to a BFile...
      fileDevice = msg->FindLong("device");
      fileInode = msg->FindLong("node");
      spoolFile = BFile(fileDevice, fileInode);

      // ...and read the "status" attribute.
      spoolFile.ReadAttr("status", buf, sizeof(buf));

      /* if the status isn't "waiting", get out. */
      if (strcmp(buf, "waiting") != 0)
    break;

      /* Set the status to "printing" */
      /* and print the file. */
      spoolFile.WriteAttr("status", "printing", strlen("printing")+1);
      SendToPrinter(spoolFile);
      . . .

The early adopters and developers on a new OS platform exhibit behavior that might be considered obsessive and irrational. When I first received my BeBox™ last year, I couldn't help but read every shred of information available in the newsgroups, and I hungered for e-mail exchanges with like-minded folks. I longed for new web sites and new software on any ftp site.

This hunger and desire reaches a fevered pitch as a 'release' date approaches. DR5, DR6, DR7... Well, it's been a long time since a release, and DR8.2 for many has been the first release. Not wanting anyone to burst a blood vessel waiting for their next fix, we've decided to release DR8.3. This is really just a maintenance release and doesn't offer any new functionality. You'll find all the details about this release on our Web site this week. The general gist is, this release is for the Power Mac only, not for the BeBox (BeOS for BeBox does not have the limitations that DR8.3 removes).

In DR8.2, the font renderer had a limited license that required us to have a termination date, past which the OS wouldn't operate. We've changed font providers, and this requirement has been removed.

Serial support wasn't included in the DR8.2 CD that shipped with MacTech. This release includes it.

There may also be a few more bug fixes, but that was not the purpose of this release. The long and short of it is, IF YOU'RE RUNNING DR8.2 ON A POWER MAC, YOU SHOULD DEFINITELY INSTALL THIS UPGRADE!!

You don't want to interrupt your endless stream of BeOS fun, so get this thing and install it immediately!!

Since we're the digital content creation platform of choice for discriminating artists, I thought I'd throw up some more code of the digital content variety. There have been quite a few MPEG encoders and decoders in the air for the BeOS. I thought I'd add the code for the Berkeley decoder just for fun.

ftp://ftp.be.com/pub/Samples/mpeg_lib.tgz

This library isn't the fastest, or smartest, or highest quality thing in the world. But the code is understandable, easy to make into a shared library, and it's free. It should be useful to those who endeavor to do similar things in the BeOS.

We will continue to provide innovative fresh fertile ground upon which you can program your heart away. And in the long run, you'll be satisfied with a job well done, until the next release.

We are, of course, not the programmer, or the user of our software. Making your customer feel stupid should be prohibited by the Constitution, and in any case, generating such feelings is always harmful to business. Put another way, while we can sometimes be forgiven for embarrassing mistakes, we won't make friends by generating feelings of inadequacy, especially if they're followed by a realization that the mistake was ours in the first place. Hence our decision to post our bugs on our Web site. Starting with developers, we want to get in the habit of mapping the minefield as accurately as we can. This will save everyone time and energy, a good reason to start with. Then, as more eyes see the range of reported problems, some pattern recognition might take place, meaning one or more individuals will pick up on a bad habit, or a regular trap, and share their knowledge with the community. In the same vein, our example might encourage BeOS application developers to do the same for their customers—and for the rest of us—with similar benefits.

This is all nice and good, but what about disadvantages? For instance, will the competition use this against us? Possibly. We might save their harried Competitive Studies people some time. But nasty bugs end up reported one way or the other, so we might as well do the reporting ourselves, thus minimizing distortion. Another possible criticism leveled at us for posting our bugs is you don't show customers the inside of the sausage factory. They don't want to know. To this, my answer is that if I start a sausage factory, I have to make a much better sausage than the established industrial meat processors. And, assuming I actually make a better product, I then make a point of seeking out sausage connoisseurs and taking them through the kitchen. They see the ingredients coming in, they watch the mixing process... I sense some problems with this kind of metaphor, the penalty, I guess for venturing out of my usual range. Still, many great restaurants feature a visible kitchen. For us, letting light in on our OS-making process is a healthy constraint. We'll be embarrassed on a regular basis, always good for the product and the soul. And we'll also get more helpful suggestions along the way than if we didn't open our doors.

Of course, as the bug reports show, we still have a lot to do and a lot to prove. Ironically, a maturing OS will mean even more bugs reported, not fewer, as our system gains more flesh and is stressed by more applications and more users.

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.