[openbeos] Re: The world as we know it
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 22 Sep 2002 18:55:29 EDT (-0400)
> "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx> wrote:
> > > If you don't want to get it, perhaps have a look at B.E.OS -
> > > AFAICT
> > > they mostly share your opinion in that regard.
> > If my explanation of why we are doing it is incorrect, please
> > enlighten
> > me. And I must say I am much, much closer to OBOS than B.E.OS
> > philosophically, for reasons that I remarked in my original e-mail.
>
> That's nice, but if you don't understand why we are aiming for binary
> compatibility (well, for you as a PPC user, we don't even do that :-
> )),
> please, just accept it. Be patient.
I'm supposed to take your word for it?
> At least I understand very much why we want to do a R5 clone first.
> And
> it's not that we don't have any ideas on how to improve things -
> there
> will be subtle and not so subtle improvements all over the place.
> But there will be only very few API changes for R1. Also remember
> that
> a normal user doesn't even see or know about the API; he will just
> see
> that R1 works better all over the place.
> Like no server restarting for networking changes, and probably the
> Media Kit, too. I am also sure that OT, which is what most users see
> from the OS, will be much more advanced than it was in R5 (well,
> okay,
> it already is, but there will be more). You will be able to search
> for
> non-indexed attributes. You will most probably be able to query other
> file systems (slow), etc. You might also be able to change partition
> sizes while they are mounted, or have a disk reorganizer application.
> Or slightly change the look of the GUI, because it's possible now. Or
> have a really nice font renderer, attach multiple monitors to your
> computer, probably have system-supported TV output, etc.
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.
> See? All that stuff, and much more, without (m)any changes in the
> API.
> API changes are not requirement for a whole bunch of improvements.
> IMO
> the Be API is nice, consistent, and modern (yeah, even without
> exceptions) - and we want to have an OS where the user experience is
> just great.
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++).
Of course we want an OS with a great user experience. But developers
are users too. The easier we make things for developers, the more we
get, the more (and better) programs are written. That you can make an
OS with an awesome user experience and a terrible API is illustrated by
the Macintosh. But that is no justification for doing so.
> Of course, for R1 we don't even plan for many improvements - but you
> can't prevent them from happening, sometimes it's really simple to
> add
> certain functionality, when you know what's needed, and had that in
> mind when implementing your stuff.
> I.e. querying non-indexed attributes took hardly two lines in the
> code
> for BFS - because the implementation allowed it.
Wonderful. But I would hope for more wide-ranging improvements as well.
> > > The problem is that we don't have one person who can decide about
> > > API
> > > changes - changing the API has a lot of impact on the whole BeOS.
> > > It's not a trivial thing.
> > Why do we need one?
>
> Because! See the new API stuff you have developed so far - from a
> design perspective most of it is nice, but *I* think it would be
> horrible to use. So do others, while other others agree with you. In
> any case, it would cause a break in the API - it would destroy the
> unity/usability of what's already there.
> To have a good API, consistency and the same philosophy everywhere is
> key - if you have too many people working on it with different ideas,
> you will most probably destroy this. That's why API changes have to
> be
> discussed intensively. Proposed by a team, discussed by all
> developers.
> And that takes time, time that we currently spend in developing - we
> have what we have, and I think it's just plain wrong to think we'd
> have
> to throw it all away to do any API extensions. AFAI am concerned, we
> don't play radical API changes, they aren't needed at all.
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?
> > Exactly. Which is why I'm arguing against binary compatibility for
> > the
> > time being.
>
> Okay, you won, the PPC version won't be binary compatible ;-)
> See, when/if we switch to gcc 3.2 we can do a lot of changes to the
> API, because we will break binary compatibility (note, that doesn't
> affect the user - he will still be able to start his old apps).
> We probably even want to continue maintaining the R5 gcc 2.95
> version,
> so there won't be any radical changes, either. But we can improve
> things a lot. The small and subtle bugs in the API that can't be
> fixed
> while keeping binary compatibility.
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).
-Nathan
--
Fortune Cookie Says:
Watson's Law:
The reliability of machinery is inversely proportional to the
number and significance of any persons watching it.
Other related posts:
