Linked by Hadrien Grasland on Sun 29th May 2011 09:42 UTC
OSNews, Generic OSes It's funny how trying to have a consistent system design makes you constantly jump from one area of the designed OS to another. I initially just tried to implement interrupt handling, and now I'm cleaning up the design of an RPC-based daemon model, which will be used to implement interrupt handlers, along with most other system services. Anyway, now that I get to something I'm personally satisfied with, I wanted to ask everyone who's interested to check that design and tell me if anything in it sounds like a bad idea to them in the short or long run. That's because this is a core part of this OS' design, and I'm really not interested in core design mistakes emerging in a few years if I can fix them now. Many thanks in advance.
Permalink for comment 475435
To read all comments associated with this story, please click here.
RE[18]: Comment by Kaj-de-Vos
by xiaokj on Wed 1st Jun 2011 11:23 UTC in reply to "RE[17]: Comment by Kaj-de-Vos"
Member since:

As an example, one could imagine handling your scenario this way :

-Before, server process broadcasted A, version 1
-Now, server process broadcasts B and C, version x, and A version 1
-The implementation of A version 1 provided by the server is in fact just a placeholder one, that calls in turn B and C depending on the situation.

Hmm. Actually, my whole point is that this method of doing things make the server full of compatibility kludges. This is not a good idea in the long run. Compatibility causes the codebase to be slower and longer and more difficult to maintain. If you implemented it as part of the translator, you have stuff working, but incur a translation overhead. This is a good thing by design! This forms a part of the "inflation" that forces the entire ecosystem to contribute.

My idea is that, instead of piling up the precious codebase with fixes, each release should come with a small translator (it may be the same for each release, if you have time to code a general one, or many small wrappers, one for each release). This would help the code be maintainable.

"Still too crude, since you can have minor behavioural changes. Mathematica is one of such examples -- each update, it will tweak some commands a little bit, and even though the parameters are the exact same, the functionality may be drastically changed such that automated updating is impossible.

In that case, compatibility with the old code is broken, so the "breaking" version number should be incremented.

In fact, I'm not sure that a secondary "compatible" version number would be needed. If the new prototype is compatible with the old one, then one should just leave it be as if it was the old version.

Version numbers do little, especially if you run a gap of a few version numbers, depending upon the scale of the problem (determined mainly by the coder, really).

Why ? They help old code not to break as long as their API version is still supported.
Now that my intention is made clearer from the one above, you should catch that I think the granularity of version numbers is too coarse. I think that it is healthy for codebases to break compatibility, minor or major, once in a while. But, it also means that the minor breaking version number will increment like crazy. This, it may as well be. However, I doubt that is going to tell you anything more than "Oh, there is a breakage". This is going to be just like the original Unix codebase -- problem areas, potential or not, is just marked with a "?", without any explanations whatsoever, and the reader (hence maintainer/developer) needs to know exactly what is the problem from there. A much more sensible approach would be to have comments telling you what is wrong, and an even better one, transition plan. If you provided information about the transition in the form of spec sheet, then I think the transition would turn out to be a lot smoother than "needs recompile now", or "API is broken; get new version immediately". Not to mention that sometimes, you just want the older version for the removed features.

As per usual, I agree with the rest; case-by-case analysis tend to give better results too. I am just wary of making code be obnoxious to the users. I refer to the RPM4/5/6 ugliness that is just mind blowing. (intentional internal inconsistency is upheld? What nonsensical obnoxious behaviour!)

Reply Parent Score: 2