At 07:50 AM 5/16/00 +1000, Ryan Heise wrote:
>rheise.os-0.1.4-pre4 can be deconstructed as follows:
>
>The first number is the major version number. It is currently zero
[snip]
>The second number is odd if this is a development release, or even if it
[snip]
>The third number represents minor releases that includes changes
[snip]
>The -pre4 suffix means that this is the 4th pre-release of what is to
[snip]
This seems pretty standard. Perhaps we should put this into the wiki as a
standard naming convention. I assumed it was understood too but it appears
that its not tha standard.
>the java package names, which is a different issue. The latter affects
>backward compatibility, and my believe is that such changes should be
>made as early as possible. This is because as more people start writing
>OS services on top of rheise.os, it will be more and more work for
>everyone to change their code when I rename my packages to jos.*. While
>my product is not _the_ java layer for JOS, I still see benefit in
>naming my classes jos.*. All I have done here is expressed my believe. I
>know you have different opinions on backward compatibility and I do not
>wish to argue about them here. Let's just acknowledge for the moment
>that we have different opinions and we are entitled to go with what we
>think is best. Later we can discuss our differences.
This seems to be more a matter of what should go into the jos.* package
space and what shouldn't. What I think would be really nice is to leave
most of the jos.* core system packages as interfaces. Then let
implementations exist outside of the jos.* package space and get sucked in
and instantiated at run-time via property files. This is similar to the
CommAPI package. The base package specifies low level interfaces, but the
actual functionality is provided by packages outside of the
space. Depending on the property file you put into your directory, the
startup code instantiates the correct serial port driver that implements
the interfaces that the package functionality is built on.
It is my impression that this is the direction that Ryan is
taking. However, at this time, due to the EXTREMELY experimental nature of
most of the code related to JOS, shortcuts will be made, and package names
will be very unstable.
Gilbert, I understand your desire to keep backward compatibility but it
simply does not seem feasible with the current codebase. It's way too
mercurial at this point. We don't know what should be in the common
interfaces and what should be implemented separately. So i think for now,
that we'll all have to just live with the inconsistencies and have file
search and replace ready when changes do happen... ;)
>It is the product name that makes it unique. My proposal for the JOS
>process API is that applications deal with a class called
>jos.process.JavaProcess.
And this seems reasonable. In all reality, we should really only
standardize on interfaces and leave implementations to anyone. That will
make JOS's implementation that ships the reference implementation but allow
anyone to replace any part with any other implementation.
-iain
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
