Ollie,
sorry for not replying earlier.
Oliver Braun wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
Some of the reasons for the namespace problems we are facing are IMHO
simply non optimal placings, e.g. "com::sun::uno::Reference" would
have belonged into "cppu" ("cppu::Reference" or may be simply
"uno::Reference". As probably most people agree with, the whole
"com::sun::star" namespace became obsolete when open sourcing
StarOffice and should have been renamed to "OOo" (or similar), and I
am sure there are more aspects one currently would like to see being
reflected in the namespaces, but ... we want to stay API and ABI
compatible, more or less rendering these thoughts useless ;-)
What about new interfaces / services ? Would it be feasible to create
"uno::" aliases for "com::sun::star::uno::" and "com::sun::star::lang"
and start using org::openoffice namespace for new interface/service
definitions ?
In general I think it would be feasible, but please see below ...
Or even better, move the basic types to ::uno and make aliases for those
in the old namespace(s) ?!
To preserve API (build) compatibility, right?
Other aliases (e.g. for beans etc.) might need to get added over time,
but at least we could start the transition.
I take the opportunity to comment on compatibility ;-) though we are
going to have a BOF at the OOo Conf 2007 regarding this topic, lead by
Juergen.
Wikipedia differentiates between forward and backward compatibility
(http://en.wikipedia.org/wiki/Computer_compatibility), the compatibility
we are here talking about is backward compatibility.
There are two types of compatibility,
- ABI (Application Binary Interface) compatibility - meaning that a
program compiled for one binary environment is able to run on another
binary environment, as long as these environments are binary (or ABI)
compatible.
- API (Application Programming Interface) compatibility - meaning that
the source code of a program compilable for one API environment may be
compiled for another API environment (without change) as long as these
environments are API compatible.
ABI compatibility is in general harder to achieve (you must know the
very detail regarding how parameters are passed, how symbols are mangled
etc. etc.) and offers less opportunity for improvement (e.g. you can not
change a function from being outline to inline). ABI compatibility is
what proprietary software vendors classical provide / require through
their lines of operating systems, applications etc.
API compatibility is superior wrt optimization, simplification,
flexibility etc., but requires the source code to be recompiled. API
compatibility is what most / many open source products provide only,
leading to the situation that it is some times hard for commercial
(without the source) vendors to provide binary (ABI compatibility
requiring) products e.g. for different Linux distributions. This is what
the LSB (Linux Standards Base) deals with.
Compatibility in general is about the "cost of adaption". Staying
compatible reduces the cost of ISVs etc. to adapt their products to
later environments, while it increases the costs of the environment
provider, as he/she explicitly needs to take steps to preserve backward
compatibility.
With OOo we currently provide ABI and API compatibility. The compatible
interfaces OOo offers are AFAIK:
- Various Uno language bindings
- Binary Uno
- C++ Uno
- Java Uno
- CLI Uno
- Python Uno
- Remote Uno
- ...
- OOo BASIC
- OOo API
- Configuration Items
- Some deployment parameters (e.g. "UserInstallation")
(http://wiki.services.openoffice.org/wiki/Uno/Binary/Spec/Bootstrapping)
- Other: Document compatibility (e.g. ODF, .DOC), ...
As we stay compatible on all these interfaces, we carry the costs of
doing so, allowing ISVs and others to reduce their costs of adaption to
a minimum. At least until now we thought this to be necessary, to get
new ISVs interested and to keep already supporting ISVs ....
Unfortunately it seems, and this is actually the reason for my long
comment, that staying backwards compatible hinders us to clean up stuff,
which really deserves it ...
From a theoretical standpoint, compatibility could be ensured by
leaving old things alone (may be after a reasonable life time) and only
introducing new stuff, though in practice this seems to be unreasonable.
Taking a look at Mozilla, it seems that they become incompatible once a
while, at least with every major version (please correct if am wrong),
and that this seems to acceptable for ISVs etc. The Linux kernel seems
to become incompatible as so often, only keeping the system call
interface stable, once a while leading to problems with binary only
drivers e.g. from NVidia or ATI.
So, the questions is, would it be acceptable for our ISVs etc. that we
become incompatible e.g. with every major? That would give us the
opportunity to clean up things (fix the namespaces), may be abandon
things and in general keep the code simple etc., basically cutting the
supply chain once a while.
Just my 2 cents,
Oliver
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
