[openbeos] Re: The world as we know it
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 22 Sep 2002 23:29:40 CEST (+0200)
"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.
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.
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.
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.
> > 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.
> 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.
Adios...
Axel.
Other related posts:
