There will be a rich API in the next version which will be accessible from C and C++ ( Corba, COM,...) , from Java, StarBasic, JavaScript and almost any scripting language. Scripting languages like Perl, Python or TCL would need a little bit of effort from the 'community' to integrate some Generic Scripting Adapter code into those languages of course.
The Design Process for the StarOffice API is not to just "publish COM APIs to" an office product. The API is being designed nearly from scratch and StarOffice is evolving to support the Interfaces and Services that have been defined in the API.
Talking 'bout startup times: just have a look at what you are comparing.
MS Office on Windows with StarOffice on Linux.
Well I DO like Linux, but I don't like people being SO proud of having a Linux box that they are getting too blind to see that even Linux might have some aspects where it is not (yet) better than other OS'es.
In a real test scenario you should have each application on each platform and compare the startup times then. Well, I do not have access to a MS Office on Linux version. But startup on Windows is NOT slower ( assuming of course you did switched the start 60% of MS Office with the OS box of for realistic comparement, of course). But startup of Star Office on Linux IS slower than startup on Windows and that while more than 90% is really the same source code.
The technical question here is why is loading of DLL's on Windows so much slower than loading of shared libraries on Linux and is there a way to improve that.
Having differences and competing in package like system configuration tools and the set of available end-user applications is no problem. But to my point of view distributions should just stop competing in stuff like being the first once to have a first alpha version of a new libc in the distribution ( probably adding even some vendor specific patches to it ).
The point is not about Linus himself ruling with an iron fist it's about lack of agreement on a version number that identifies a set of basic packages. Well RPM is at least a good thing to have, but it would be really nicer to have a common version number for the stuff that almost everybody uses.
And it would also be nice to have some ways to separate the playground ( the field where we can experiment with new ideas in the software) from the end-user-ready-usable-stable-system area. The kernel already does that so why not doing it with something like a common base package.
Getting up some kind of voting system for decisions like when is the right time for a feature stop in the playground version for getting a new version number for a stable-end-user-ready version should be possible, don't you think ? Having something to rely on does not necessarly imply having a single person to rule.
Or to put it into annother type of view, do you really think that Linux should compete with Windows in the area of being the OS with the greatest combination of different sets of system library versions that can be found in the system directories of different users. Do you really want to encourage linux application programmers to override system files on application installation like it's already to often done on Windows ?
What problems can possibly be so bad? Have they heard of GNU Autoconf?
Well, I kind of have seen lots of inter-operability problems with a larger program package on linux.
AutoConf might be able to help on a lot of inter-operability issues but it does not solve all.
And what's wrong with just concentrating on one distribution?
Lot's of things are wrong with that. Especially the risk to be blamed by users that your stuff doesn't run on their other distribution because they do not look into all the technical details and probably do not care about that there are some and that's probably their right, they are users ( assuming that Linux IS ready to be used by so called end-users )
Being blamed by Users that something doesn't work right without having a fixed point to concentrate on for your development and quaility insurance on OS depenencies issues ( which is stuff that is not part of your program ) is what I really consider to be the interoperability problem with linux.
And it would be nearly easy to solve ! All that has to be done is that the major distribution get their heads together and define something like a common BASE LINUX CORE Definition ( agree on a set of BASE packages of their distributions and give that thing a VERSION NUMBER ). This base package definition should consist of the basic directory structure ( FHS standard ) kernel version, libc, stuff like file and shell-utils, X11 core libs ). If developers would have that thing they would be able to develop a package for the current base version X and clear statements about a package like runs on BASE X or runs on Linux Distributions using Linux Base A - Linux Base C could be made.
You might experience that stuff like the following can happen to you on Linux:
Program does a little bit more math calculation than the average. Some of the Developers found a useful libc function exported ( declared as extern void ) in some/usr/include/* file and uses it. Some month after shipping a newer libc is out (Version changed from x.y.z to x.y.(z+1) ). That one does no longer contain that routine. Program doesn't work on distribution X (new version out with that libc) or personally upgraded user systems. You know what happens: "new libc is GREAT, everything works fine except...". Developer probably even gets blamed by the libc developers and others for having dared to have use that routine.
Well autoconf wouldn't have helped in that case, I don't think it did check for that routine before the libc changed nor do I think that it would check now.
This example also shows that Linux kind of lost some of it's own traditions from the very beginning: when a incompatible change is introduced to a library the major version must be incremented not the minor.
And than in the end when you really thing about the term 'different flavours of Linux' it it's not only distributions, there are almost as many flavours as there are users ( i've updated this, you've updated that, found this new stuff there... ). What is needed is some basic stuff you can rely on, a base system definition oh well and probably that even/odd numbering scheme with that as the Linux kernel does would also be a good thing.
And us Debian users would find a way to make it work on our systems too.
Consider that not every end-user knows how to use autoconf and consider that not every end-user has the time and knowledge even just recompile stuff for several hours, let alone the skills needed for finding ways to make things work.
StarView is dead. It's now VCL ( virtual class library ) and it has evolved quite a lot from the stuff of 1994. Although if you happen to know a little bit about StarView you will recognize some Classes you've seen there some basic concepts have changed totally.
Slashdot Mirror
There will be a rich API in the next version which will be accessible from C and C++ ( Corba, COM, ...) , from Java, StarBasic, JavaScript and almost any scripting language. Scripting languages like Perl, Python or TCL would need a little bit of effort from the 'community' to integrate some Generic Scripting Adapter code into those languages of course.
The Design Process for the StarOffice API is not to just "publish COM APIs to" an office product. The API is being designed nearly from scratch and StarOffice is evolving to support the Interfaces and Services that have been defined in the API.
Talking 'bout startup times: just have a look at what you are comparing.
MS Office on Windows with StarOffice on Linux.
Well I DO like Linux, but I don't like people being SO proud of having a Linux box that they are getting too blind to see that even Linux might have some aspects where it is not (yet) better than other OS'es.
In a real test scenario you should have each application on each platform and compare the startup times then. Well, I do not have access to a MS Office on Linux version. But startup on Windows is NOT slower ( assuming of course you did switched the start 60% of MS Office with the OS box of for realistic comparement, of course). But startup of Star Office on Linux IS slower than startup on Windows and that while more than 90% is really the same source code.
The technical question here is why is loading of DLL's on Windows so much slower than loading of shared libraries on Linux and is there a way to improve that.
Having differences and competing in package like system configuration tools and the set of available end-user applications is no problem. But to my point of view distributions should just stop competing in stuff like being the first once to have a first alpha version of a new libc in the distribution ( probably adding even some vendor specific patches to it ).
The point is not about Linus himself ruling with an iron fist it's about lack of agreement on a version number that identifies a set of basic packages. Well RPM is at least a good thing to have, but it would be really nicer to have a common version number for the stuff that almost everybody uses.
And it would also be nice to have some ways to separate the playground ( the field where we can experiment with new ideas in the software) from the end-user-ready-usable-stable-system area. The kernel already does that so why not doing it with something like a common base package.
Getting up some kind of voting system for decisions like when is the right time for a feature stop in the playground version for getting a new version number for a stable-end-user-ready version should be possible, don't you think ? Having something to rely on does not necessarly imply having a single person to rule.
Or to put it into annother type of view, do you really think that Linux should compete with Windows in the area of being the OS with the greatest combination of different sets of system library versions that can be found in the system directories of different users. Do you really want to encourage linux application programmers to override system files on application installation like it's already to often done on Windows ?
What problems can possibly be so bad? Have they heard of GNU Autoconf?
Well, I kind of have seen lots of inter-operability problems with a larger program package on linux.
AutoConf might be able to help on a lot of inter-operability issues but it does not solve all.
And what's wrong with just concentrating on one distribution?
Lot's of things are wrong with that. Especially the risk to be blamed by users that your stuff doesn't run on their other distribution because they do not look into all the technical details and probably do not care about that there are some and that's probably their right, they are users ( assuming that Linux IS ready to be used by so called end-users )
Being blamed by Users that something doesn't work right without having a fixed point to concentrate on for your development and quaility insurance on OS depenencies issues ( which is stuff that is not part of your program ) is what I really consider to be the interoperability problem with linux.
And it would be nearly easy to solve ! All that has to be done is that the major distribution get their heads together and define something like a common BASE LINUX CORE Definition ( agree on a set of BASE packages of their distributions and give that thing a VERSION NUMBER ). This base package definition should consist of the basic directory structure ( FHS standard ) kernel version, libc, stuff like file and shell-utils, X11 core libs ). If developers would have that thing they would be able to develop a package for the current base version X and clear statements about a package like runs on BASE X or runs on Linux Distributions using Linux Base A - Linux Base C could be made.
You might experience that stuff like the following can happen to you on Linux:
Program does a little bit more math calculation than the average. Some of the Developers found a useful libc function exported ( declared as extern void ) in some /usr/include/* file and uses it. Some month after shipping a newer libc is out (Version changed from x.y.z to x.y.(z+1) ). That one does no longer contain that routine. Program doesn't work on distribution X (new version out with that libc) or personally upgraded user systems. You know what happens: "new libc is GREAT, everything works fine except ...". Developer probably even gets blamed by the libc developers and others for having dared to have use that routine.
Well autoconf wouldn't have helped in that case, I don't think it did check for that routine before the libc changed nor do I think that it would check now.
This example also shows that Linux kind of lost some of it's own traditions from the very beginning: when a incompatible change is introduced to a library the major version must be incremented not the minor.
And than in the end when you really thing about the term 'different flavours of Linux' it it's not only distributions, there are almost as many flavours as there are users ( i've updated this, you've updated that, found this new stuff there ... ). What is needed is some basic stuff you can rely on, a base system definition oh well and probably that even/odd numbering scheme with that as the Linux kernel does would also be a good thing.
And us Debian users would find a way to make it work on our systems too.
Consider that not every end-user knows how to use autoconf and consider that not every end-user has the time and knowledge even just recompile stuff for several hours, let alone the skills needed for finding ways to make things work.
StarView is dead. It's now VCL ( virtual class library ) and it has evolved quite a lot from the stuff of 1994. Although if you happen to know a little bit about StarView you will recognize some Classes you've seen there some basic concepts have changed totally.