Hi,
>(2) implementing something as close as is humanly possible to the JavaOS
>API(s), which will be more work in the short term, but maybe less in the
>long term, and which will obviate the consensus-building group-grope
>problem we currently have, which makes it much harder to get anything
>done that involves more than one person...
>
>Basically, option (1) is the "let's re-invent the wheel" approach, and
>(2) is the time-honored, Open Source "chase the tail-lights" approach.
>As much as I like designing my own APIs (of course, they would be far
>superior to and more aesthetically pleasing than the JavaOS ones --
>*N-O-T*), I'm kind of leaning towards option (2). I mean, hell, we're
>not redesigning the Java language, the bytecodes, or the java.* classes,
>so...
>
For the Option (2), personally, I don't prefer this approach. Since all the
APIs
are provided by Sun. Once Sun found that the APIs is not good enough, they
will change it (e.g. Swing). If we follow Sun's APIs, we need to "re-do" all
our
works. Is that good ? I don't think so. One more thing, right now, all Of
Products
of Sun Java are not OPEN SOURCE. If we follow Sun's APIs, THEY MAY NOT
ALLOW US TO RELEASE SOURCE.
Regards,
Hilary
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
