What follows is the template for an email that will go out to all of the people who signed up for WalterCon. Some payment details and room assignments will be added.

We are into May already and it is just over a month before WalterCon!

This e-mail is to confirm your registration. I assumed that you would want a double occupancy unless otherwise stated.

Room prices are slightly higher than originally thought due to taxes, but more people will be able to double up than expected.

• $30 for attendence only
• $75 for double occupancy (i.e. we assign you a roommate)
• $120 for single occupancy (i.e. you are alone or with non-attending roommates)

Details on how to pay will be coming soon.

There are a few (two) rooms empty from our default fifteen. If you would prefer a single room for the full $90, please let me know - I am sure that the hotel will be thrilled to sell us more rooms.

OK. Who will be there? The current list of OpenBeOS developers who will be there is:

• Michael Phipps
• Tyler Dauwalder
• Gabe Yoder
• Darkwyrm
• Andrew Genduso
• Andrew Bachmann
• Kevin Field

Here is our planned agenda. This may change at any time.

June 19

• 9AM Intro and Welcome (Michael Phipps)
• 10AM State of the Project, New name and site unveiled (Michael Phipps)
• 11AM BeUnited presentation (Simon Gauvin or Deej)
• 12PM Lunch
• 1PM Interface Kit (DarkWyrm)
• 2PM ScreenSaver and Translation Kit (Michael Phipps)
• 3PM Storage Kit (Tyler Dauwalder)
• 4PM Input Kit and Device Kit (Michael Phipps)
• 5PM Media Kit (Andrew Bachmann)
• 6PM Dinner
• 7PM - 10PM - Free Time/Coding/Whatever

June 20

• 9AM Welcome Back (Michael Phipps)
• 10AM Applications brainstorming (Michael Phipps)
• 12PM Lunch
• 1PM R2 Brainstorming (Michael Phipps)
• 3PM Marketing/Business Brainstorming (Michael Phipps)
• 4PM Windup and closing (Michael Phipps)

Currently, we have more than thirty people attending! The conference room is "spec'ed" at twenty-five, so unless we have cancellations, we really can't accept new registrations.

Because the number of people exceeded our expectations, we want to provide each attendee with a t-shirt. Please get back to us with your t-shirt size as soon as possible.

Looking forward to seeing you there!

Michael

Yep. I remember when Be first announced Replicants. They were going to be the next ActiveX. I wonder what ever happened to them.

The sad truth is that absolutely nothing happened to Replicants. Almost no one ever used them. No great mountains of applications ever came out for them. I was chatting with some people the other day on IRC and we wondered about this. Needing to write an article and not sure what to write, that commiseration came back to mind.

I started looking around for "official" documentation on Replicants, not wanting to recreate the wheel. I found very little. There were a few newsletters that mentioned Replicants, and the documentation in the BeBook about BeDragger and BShelf, plus the sample code. I was very surprised not to see more. With some more digging, I managed to find the introduction that Peter Potrebic gave at BeDevCon ྜྷ. I believe that I was at that session. I recommend reading it at http://www.beatjapan.org/mirror/www.be.com/developers/aug_dev_conf/transcripts/extending_replicants/index.html.

The question that I set out to discover the answer to: What is a replicant, and how do I play with one? A replicant, quite simply, is a BView. The "trick" to a replicant is that the BView has an Archive() function (something that any BView can have but people rarely seem to bother) and a link to a BDragger--a handle to move the BView around with. When you grab the handle, it tells the BView to archive itself. The app_server then treats that archive just like a drag and drop (as if it were text or a bitmap). The other side of the coin is the BShelf, which is a special BView that knows how to receive BView drag and drop messages. It loads the application or add-on that created the BView, searches for the archived class's Instantiate() function and calls it. Voila--the code from one application is now running in another.

How did I play with it? Some time ago, I had started something called kitView. It was to become what BeHappy did become, down to using NetPositive as a replicant. I dug the code out, removed the list views and rebuilt. Sure enough, the code still worked! OK, so that covers the "receiving", or BShelf side of the replicant. Time to write a "sending" side of the replicant.

I had never done this before and there were many pitfalls on the way, including crashing the app_server multiple times. You have been warned. :-D I created a simple application called "grapher". Its whole purpose in life is to draw a simple bar graph with hard coded values. I actually copied kitView and modified it.

Step 1: Adding the BDragger class. BDragger is the little handle that you can move the BView around with. The handle can be a child of the BView, the parent of the BView, or a sibling. You could put the handle on the other side of the window (sibling).

Step 2: Make the BView archivable. If you hadn't subclassed your BView already, well, now you have to. Create an Archive() method (look at BHandler's BeBook section). Any member values of your BView that are necessary, you need to save into the BMessage. The "Clock" sample code has a good, easy example of this. You also need to call AddString() to add the "add_on" field, populating it with your app's signature. Make sure that you set the app's signature using FileType or resources. Otherwise your replicant will not work and you will not know why.

Step 3: Create a constructor for instantiating your BView from a BMessage. This is the constructor that takes only a BMessage as a parameter--documentation is in the BView section of the BeBook. Any data that you saved into the BMessage in Step 2 you need to read from the BMessage here and populate the member variables. Note that static variables do not work across application boundries. So if you intend to share data across different instances of views in your application using statics, they will not work properly with Replicants.

Step 4: Create a static method called Instantiate(). This static method should call new to create a new instance of your BView, passing it a BMessage.

Finally, I wondered if you could print a replicant. I added a print button to kitView and added some simple code to create a new print job containing the BShelf. It works!

There are many areas of exploring that I did not do with this sample code. I did not install a pop-up menu, for example. I did not test to see if I could do things like create windows as a replicant. I did not attempt to make my replicant resizable--it would be a very neat thing to resize your replicants inside the shelf.

After playing with Replicants, I believe that they are easier to use than I had ever thought. Having written my first one, I would bet that I could write another in an hour or so (outside of BView functionality). There is a lot of power inside Replicants. Be's demos, I think, set the wrong tone for Replicants--as toys that are not really useful. I would like to consider another direction for them: as an OpenDoc or ActiveX replacement. You can create Replicants with a message-based API--no fragile base class, no headers, no C++ dependence, etc.--something very powerful to think about.

In many ways, the BeOS community is different from the community of other operating systems. If you look at the Windows community, for example, you will see that, in general, it is a very profit-minded community. There is a lot of shareware and for-profit software out there. The freeware in the Windows community, in my experience, is mostly Linux ports or stuff that is pretty low quality. In contrast, in the Linux/BSD communities is mostly free software with a few exceptions. The free software ranges in quality but tends to be pretty good, if not great in most cases. The BeOS community was, in its largest days, a mix of these. There were a number of companies that put out software, but there was a lot of good freeware, as well.

It is my firm belief that the BeOS community failed Be, Inc. in a large number of ways. And Be, Inc. failed the community in just as many ways. I say this not to indict anyone or make them feel guilty, but to attempt to make this situation better for the future. Initially, Be was pretty open--information flow between the company and the community was very good. The community knew, for the most part, what was coming in new versions of the OS and the company knew what developers needed and were working on. There was a healthy ebb and flow. BeDevTalk was filled with Be engineers. As time went on, two things happened. The community grew and was no longer quite so tightly knit. Be, Inc filed for an IPO. Those two things pushed the parties apart in a way that was not good for either group. When you add into that the repeated focus shifts and the developers (mostly the bigger companies) who didn't live up to expectations, it was a recipe for disaster.

To some degree, the BeOS community is looking for a "new identity". It seems obvious that the parent-child relationship that was Be-->Developers/Users doesn't work. We aren't big enough (and don't want) the "messenger from on high" approach that huge companies use. At the same time, I don't think that the "everyone do what you want and let evolution clean out the crap" approach of other OSS groups will work, either - we aren't big enough for that.

It isn't yet clear, to me, how all of this should turn out. One of the advantages of a completely open source and non-profit organization is that there will never be any question of the communication coming out of OpenBeOS. Exactly what is going on is perfectly available to anyone. Our CVS is Web available. You can browse and see exactly where we are. The real work (and the challange for me) is to convert a couple of million lines of code into a few paragraphs that tell people what is going on. I know that people would like to see more stuff on the main page. As we hit milestones, we are posting, but milestones only come every mile.

The other side of this coin is developers communicating with us. This was the point of the Glass Elevator project: To give developers direct feedback into the direction that would be chosen for R2. The problem that we have in GE is that it is a discussion forum. We have (literally) years of archives of e-mails. Someone (or several someones) is/are needed to put all of that into a reasonable format for the actual OS devs to peruse. Taking a thread of 50 e-mails and converting it into a reasonable sized proposal is very time consuming, and there are thousands of emails to work on. If some very energetic person is interested, please let me know.

I was sitting at lunch the other day thinking about WalterCon, as I do a lot these days. As you can see in the above agenda, I have a planning session for applications. There is a sort of a chicken and the egg issue with applications and OS features. I have used the maxim "if five different applications for typical users require some code, it should be part of the OS." I don't quite know if this is true or not, but it sounds like a good place to start. Take, for example, instant messaging (IM). Most people think of IM as something in its own application. But here are a few more cases for IM as a general tool: collaborative writing, network games, professional tech support, combined with e-mail ("User mphipps is on-line with AIM - would you like this e-mail sent to him via instant message?"), workflow processing ("the timesheet for mphipps has been submitted for your approval. Open it now?"). IM, IMHO, belongs in the OS. So from features, you can easily start to see how to improve your applications (bottom up development). On the other hand, as I started to consider the applications that I see as necessary for OpenBeOS to be successful on the desktop, common features started popping out like champagne bubbles.

I think that an iterative collaboration between applications and features will allow us to design R2 in a fashion that brings us the most applications and power for our buck. I wish everyone could be at WalterCon. I hope to webcast it and to take ideas in realtime via IRC or BeShare. But understand, too, that every idea that we come up with at WalterCon is not a promise of what will go into R2. Especially since many of the developers will not be there, it is not at all fair to commit to something that they have no input into.

Having said all of this, I would like to put a radical idea out there. Many of the OS developers, myself included, have put their application ideas aside to work on OpenBeOS. Without the OS, there is no platform for our apps. On the other hand, without the apps, there is no point in the platform. This is the infamous chicken and the egg dilema that Be faced. I know that there are a lot of developers out in the community who are working on other things. Some are really critical things, like the Mozilla port. Others are... less visible. What I would like to ask every developer to do is this: put everything else aside for one month. Put one month into OpenBeOS. We have lots of areas that can be finished in one month of concentrated development. I would love to be able to demo a bootable, functional alpha of R1 at WalterCon. What would that take? A lot of hands working on a lot of things. Parallelism is the only way that modern software can be written. We have need in the Interface Kit, networking, kernel, midi, etc. I am only looking for developers. If you are a fairly good (not a newbie) developer who will commit for a month (or longer), we really need you. A concentrated push here could bring about a lot of those milestones that we all love to see so much on the news page.