The BeOSJournal recently fired off an email to the hard working Tyler Dauwalder from openBeOS, who is working on the Registrar along with Ingo Weinhold, and he replied in short order.

We'd also like to thank Ingo Weinhold for his wonderful work, whom as Tyler told us via email, a lot of work would not have been possible if not for Ingo. Great job!

Now, on to our mini-interview...

TBJ : We're glad to hear about the recent progress with the Registrar reaching its second milestone; can you tell us what a registrar is, and what yours can do at this point, in real world terms?

Tyler : The BeOS registrar is a program that runs quietly in the background, serving a variety of tasks. A few of the major tasks are:

• The registrar manages a list of running applications. For example, when one application wants to talk to another application, it asks the registrar the "address" of the destination program so it knows where to send messages to.
• The registrar facilitates the system's clipboards for passing data via copy/cut/paste operations.
• The registrar manages the system's file type database (i.e. the MIME database), which contains information such as which applications support a given file type, which icon is associated with a given file type, etc. Also, the registrar periodically runs a "sniffer", which crawls through your hard drive attempting to identify the types of untyped files.
  
• The registrar orchestrates the sytem shutdown sequence, asking running applications to quit, notifying the kernel that it's time to shut down, etc.

Our registrar currently handles registrations from OpenBeOS applications, is able to manage inter-application communication, and provides complete MIME database functionality.

TBJ : When do you expect to reach milestone 3, and just how difficult is the road ahead?

Tyler : Well, we started discussing the registrar four months ago, and started coding three months ago. The remaining tasks should be less involved than those already completed, so I would hope we'd be able to finish up milestone 3 a bit more quickly. :-)

TBJ : How compartmentalized is the work on the registrar? Will there ever be a point where you can not continue until something X has to be completed first? What is that X?

Tyler : The basic registrar functionality needed to be implemented one piece after another, but that sort of linear progression is not so necessary anymore. The handful of remaining tasks in particular are unrelated enough that they could, for the most part, be worked on independently and concurrently, assuming we had the resources to do so.

As to any potential roadblocks, when it comes time to finally handle the system shutdown services, we're going to need our own app_server and BWindow implementations in order to display the system shutdown window we're all familiar with. And to get everything technically completed, it's all going to need to be running on our own kernel.
But other than that, I believe all of the remaining functionality should be implementable whenever we get around to making it happen. :-)

TBJ : Thanks Tyler... It really helps a lot to allow everyone have a small glimpse into the world of the openBeOS coders...

Tyler : My pleasure. :-) Thanks for continuing to be an active part of the BeOS community. :-)

-Tyler

You can find out more information about Tyler and Ingo's work at the openBeOS website, in the Storage Team area. Thanks again to everyone who is making openBeOS a reality. Without your hard work and dedication, it would be a far more depressing world to compute in. ;-)