Hi Thorsten,
as a general preface, let me say that I agree to Jürgen that we should
separate UNO API incompatibility from UDK API incompatibility. While I
think that some ideas can be applied to both, my gut feeling is that
both topics are too different to be discussed together.
preface II: Thanks for bringing this up, that's a long-standing issue,
which desperately needs to be addressed.
> Decide on preconditions for change:
> - API was badly designed (architects/pleads to vote if not
> concordant)
> Have a list of 'design smells' here, e.g.:
> * missing exception specifications
>
> - API is unused
This is not a precondition, but an indicator for allowance, actually.
> - API implementation is too expensive
> ...
> Decide on constraints:
> - how many clients does this API have
> * inside OOo code
> * (estimated) use outside OOo repo
> * (estimated) number of implementers not reading
> interface-announce
>
> For the latter two, if (at most) recompile is enough, any number
> of implementers won't block change.
>
> For the latter two, if syntactic changes are required, have
> architects/pleads majority in favor of change?
>
> - how 'bad' is the API really – if bad enough, change anyway?
I think that we might need to define certain types of changes, and
define the constraints per type.
For instance, with an API which actually is intended to be used by
clients, but not to be re-implemented by external components (this holds
for a lot of services/interfaces which effectively describe the current
implementation in OOo version X), I think it should be allowed to, say,
add new methods to existing interfaces, or new interfaces to existing
services. For a Java/Basic/Phython/Basic/BeanShell/JavaScript client
(extension), this would be completely transparent. C++-clients might or
might not be affected (chances are they are).
For an API which is intended to be implemented by extensions (say, a
spell checker), adding new methods will immediately make the extension
stop working, so here we probably need other constraints.
Coming from the other side, perhaps we should classify the different
types of possible changes, and decide (judging from the pain the
"changes class" would bring for API clients and OOo users with
non-adjusted extensions) for every class under which circumstances such
a change is allowed.
Yes, I think we need a fine grained rule set. Im convinced that anything
like "For every major version, you are allowed to change everything you
claim is badly designed currently" will lead to big problems, because it
will be too easy to misuse it (intentionally or not ...).
Different changes which come to my mind:
- adding/removing exception specifications
- adding/removing interface methods/attributes
- adding/removing interfaces to services [1]
- adding/removing method parameters
- adding/removing base interfaces to existing interfaces
(each of those items is probably two different ones, actually)
- ...
I don't have an opinion on *all* of those, but my *very personal* wish
list contains:
1. I want to be able to fix the exception specifications in our
interfaces. All those methods not allowed to raise anything except a
RuntimeException (thus sometimes wrapping their errors in a
WrappedTargetRuntimeException - what a stupid concept, sorry) just
make reasonable error handling hard up to impossible.
2. I want to be able to add methods to (some) of our interfaces. For
instance, something like XDatabaseMetaData, modeled after a
ten-year-old version of Java's DatabaseMetaData, suffers for *years*
from its non-extensibility (which is highly different from its
archetype: JDBC's DatabaseMetaData is extended with every version).
3. I want to be able to add new interfaces to existing services, if
those services actually describe "the current OOo implementation",
without declaring them as optional (and lying to my API documentation
readers this way).
4. I want to be able to use the cool new (huh, not really new)
multi-inheritance feature for interfaces, consolidating decade-old
interfaces, and using the merged versions where the single versions
were used before. For instance, if I have XResultSet and XRow, and a
method taking either one of those, with a comment in prose "this
*must* also support <the other one>", then please give me an
XResultSetRow (or let me derive XResultSet from XRow), and allow me
to change all method parameters taking/returning an XResultSet to
actually take/return XResultSetRow, greatly relieving all clients
this way.
5. I want to be able to fix mis-designed interfaces. XDatabaseMetaData
is a good example, again, as it states things like "if this parameter
is NULL", talking about a string parameter ... too closely copied
from Java, I'd say.
Another example: Ever tried adding a default-VOID property to
an XPropertyContainer? Uhm, you've lost, the type is implicitly
defined by the given value.
6. I want to be able to remove existing types, fixing design errors this
way. Why do we have a ucb.DoubleInitializationException and a
frame.AlreadyInitializedException, with the exactly same purpose,
but no util.AlreadyInitializedException, to be thrown by
XInitialization::initialize?
1. - 3. are things which IMO can be done unconditionally - there won't
be much pain for clients. The other 3 are more difficult, but should be
possible with a reasonable mitigation path.
> Who decides?
Difficult ... Having a gatekeeper (or multiple fatekeepers) does not
really sounds feasible. I would hope that discussing the changes in
public until a consensus is reached would work out.
Ciao
Frank
[1] And no, please nobody say "old-style services are dead". They exist,
there are plenty of (evolving) implementations and clients for them,
and changing this situation is a challenging task of its own. Plus,
the discussion whether it's *worth* changing this situation is a
challenging topic of its own. Let's keep all this separate, please.
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
