"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.