Stephan Bergmann wrote:
Arthur wrote:
And I've found a discussion about this on this list, which talks about
an effort within the OOo project:
http://api.openoffice.org/servlets/ReadMsg?list=dev&msgNo=8083
Has this lead to the kind of API we have now? Or is there some code in
development to be looked at?
See my repsponse from back then at
<http://api.openoffice.org/servlets/ReadMsg?list=dev&msgNo=8224>. This
has been introduced as "shiny new UNO" a long while ago (see
<http://marketing.openoffice.org/ooocon2004/presentations/friday/shinyhappyuno.pdf>)
and is the foundational work by which new UNO entities (interfaces,
services, etc.) can be designed that are easier to work with in the
various UNO language bindings; however, the vast majority of existing
OOo UNO API has not (yet?) been improved to make use of those new features.
as Stephan has already mentioned the technical stuff is already there
and we have on our to do list to use this new style UNO features for new
API's and we want also adapt existing API's where it is easy possible to
make use of this new features. But of course the priority is
unfortunately low and i am would be happy if we could go forward with
this faster.
A further possibility would be to discuss a cut. That means we would
break with our compatibility assurance, redesign some important API's,
remove resign bugs, maybe improve UNO in some parts where possible etc.
But that is of course an important question and should be discussed and
analyzed in detail. I am sure we would make some other mistakes in the
design and in general the compatibility is a great benefit for users
even when it is more difficult for the developers. Read some interesting
blog related to compatibility
http://blogs.sun.com/GullFOSS/entry/breaking_a_lance_for_backwards
Arthur has used the word "unjavaish", but you should keep in mind that
you use a component technology and that you can use the same API from
different languages. That should not mean that it would be impossible to
make Java UNO more Java like (today). See for example the newer .NET
UNO language binding which is smoother to use in a .NET env than Java
UNO in Java because we have learned.
But currently the compatibility is still more important and we don't
want to break existing solutions.
You can be sure that we have this on our radar ...
Overall, it would be interesting to know how an incompatible change of
the API and maybe UNO would be accepted.
Juergen
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
