[openbeos] Re: The world as we know it

  • From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 23 Sep 2002 20:51:13 EDT (-0400)

> >Sure, you can do a lot without changing the API, without making any 
> >really major modifications to the system design. You can make a 
> > better 
> >OS. But the fundamental design of some things (like many of the 
> >inheritance issues in the API: see BSerialPort for an example) can't 
> > be 
> >fixed without a more wide-ranging overhaul. I'm not even proposing 
> >radical overhaul, just the recognition of systemic problems, and 
> > that 
> >we fix them. That we look at OpenBeOS systemically, instead of just 
> >modifying a piece here and there.
> Sigh. We have been over this more times than I can count.
> We are supposed to be doing this. On Glass Elevator. That *IS* your
> charter. To look these things over and make suggestions. Take that 
> bull
> by the horns. Don't make a message here or there about it. Deliver 
> some
> great, grand design. We will look at it with a fair and unbiased 
> opinion.
> Far more so than we will distractions like this, here and now, when 
> we have
> a part of the course already plotted. 

It is indeed. I just wish we had more people over there who were 
actually coding this stuff...

My main point is communication. We have all these teams and sub-teams, 
and none of them talk to each other! If you want to solve system-wide 
issues, you need to talk system wide. And if they do talk, people get 
pissed at them for being off-topic. It's a trade-off between coding 
efficiency (you walk fastest if you look at nothing but your shoes) and 
design (how will you notice the broken streetlights unless you stop and 
look up?).

> >It is nice, consistent, and modern... compared to the MFC. Outside 
> > of 
> >that, it is actually not particularly consistent (several different 
> >error-reporting strategies, inconsistent string formats, 
> > inconsistent 
> >use of abstract base classes), not particularly nice (Why the heck 
> >doesn't BMessage inherit from BFlattenable? And who thought up the 
> > type
> >-specific data retrieval interfaces for BMessage?), nor particularly 
> >modern (other than classes, it displays a complete aversion to all 
> >features of C++).
> A lot of this came about from different people writing things at Be 
> at different
> times. This is a place where some consistancy would be good. IIRC, 
> BFlattenable
> came long after BMessage. I want to say around DR9. I could be wrong, 
> though.
> I will give you a caveat, though, about the BMessage data type 
> retrieval stuff.
> I used to think a lot like you do. I wrote a system at my day job for 
> database I/O.
> I used a generic method for populating a field that was overloaded 
> with many 
> different types. Unfortunately, C++ was overly helpful with its built 
> in type casting
> and caught me many times with trouble. These are harder to make right 
> than they
> sound. And harder to use for developers than they sound. Really.  Not 
> that it can't
> be done, but it isn't as trivial as it seems. A note from the 
> trenches.

I know what you mean; I tried it too. Yike! The naming is good, the 
retirieval mechanism inefficient. I don't know how I would improve it 
without exceptions (that's much of the reason I like them), but return-
by-pointer completely blows. But that's a topic for another ML...

> >Wonderful. But I would hope for more wide-ranging improvements as 
> > well.
> Patience, young Jedi. Remember that, among other things, we are all 
> learning.
> None of us have ever done this before. You would have us learn how to 
> write 
> an OS, design one, build it, test it and, build a killer organization 
> at the same time.
> I very much thank you for your faith in our abilities. But I can tell 
> you that it is
> *WAY* more than any volunteer group can chew.

Heh. We would stand well by a little communication though, and getting 
our noses a little farther out of our current page of the Be Book.

> >True enough on the philosophy bit. But even you agree that we don't 
> >just need a single person. And would you seriously support keeping 
> > the 
> >seriously over-extended and generally screwed up API we have now?
> I wouldn't support that statement at all. The API needs some help and 
> some
> extension. But I would hardly call it seriously over-extended and 
> screwed up.

Apologies for hyperbole, I'm sure. But some of it really *is* screwed 
up. As for over-extended, as you pointed out with BMessage, not only 
was it not designed from the bottom up, it was designed sideways and 
upside down and through funky interior utility hatchways. Lots of the 
API is left over from DR8.

> >Wonderful. That's when I would add a new API too. And we would of 
> >course keep the R5 version (because of the different ABIs, they can 
> >even go in the same shared object).
> There is a point at which this will become unwieldy. I don't know 
> when or how that will come about. But at some point, BC should be 
dropped. Will that be in R2? R3? I don't know. I am not looking that 
far ahead. We can't at the moment. But it will happen. And the fewer 
closed source apps that there are, the sooner I think that day will 

Then we can toss those symbols. But I agree entirely. As a temporary 
expedient, BC is great. But beyond that, it's a serious restraint on 
our ability to improve the system.

Fortune Cookie Says:

Adolescence, n.:
        The stage between puberty and adultery.

Other related posts: