Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
Second, we neither have nor plan to have in place a mechanism to detect
that some UNO component/OOo extension uses an old revision of some
unpublished API. That is, there will not be any warning if you deploy
such a component/extension into an environment where it will not work,
and at runtime using that component/extension can have unexpected effects.
Perhaps we should have such a mechanism then.
Going away from the "every released API must be stable" paradigmn by
introducing the "published" keyword/feature was a great relief, and
prevented some immature interfaces already (we have enough of them in
the API created before).
Now what you're saying is that efectively, we're in the same situation,
again: Don't change any released API, as existing extensions might rely
on it, and will disbehave (and probably crash, if they're C++) if used
in conjunction with the new API. This makes, IMO, the "published"
concept absurd.
No, I did not say that unpublished API cannot be changed in general. I
said that there might be cases where "some unpublished API [...] is
badly needed by UNO component/OOo extension writers" and might thus be
misused by them against all warnings. And I just wanted to raise
awareness that in *such* a case, it might be a bad idea to change the
unpublished API later on. (This is not specific to unpublished UNO API;
if any kind of important document is labeled "draft" and stays that way
for long enough, people will start to rely on it, and nobody will dare
to change it and break the de-facto world.)
Said that, I strongly vote for having a versioning mechanism.
I also got a Sun-internal mail that requested a detection mechanism for
usage of broken unpublished API, and a versioning mechanism for
published API. Let me explain to you why I think that what we have now
is all we can reasonably get:
(The following is about OOo extensions, but most of it also applies to
the simpler UNO components and a plain URE.)
First, a mechanism that can detect that some extension is using outdated
unpublished API (i.e., shall be deployed in an OOo where a changed
version of that API exists): This could work if an extension contained
descriptions of all the unpublished API it uses. Then, at deployment
time, this data would be checked for consistency with the OOo's type
data. However, the problematic part is to assemble the list of
unpublished API an extension uses: You cannot do that automatically,
for one because of practical issues (how would you do it for a
dynamically typed language like Python where the used types are not
necessarily mentioned in either the source text or the compiled
binaries, if any?), for another because type information can be obtained
dynamically at runtime via
com.sun.star.reflection.TypeDescriptionManager, so that static analysis
cannot in principle give you that list. Also, including information
about all unpublished API that could *potentially* be used by an
extension is not an option, as this would even hinder those extensions
from being deployed later on that would never actually use any (changed)
unpublished API. So, the only solution would be to assemble that list
manually, which IMO is tedious and error prone.
However, if you are willing to list unpublished API (at a level that
seems appropriate, like either a whole API or only individual types) in
extensions using it, you can leverage the extension dependency feature
introduced in OOo 2.0.4 (see
<http://specs.openoffice.org/appwide/packagemanager/extensiondependencies1.odt>):
For each version of an unpublished API, invent a dependency token. In
an extension that uses unpublished API, record the corresponding
dependencies. In OOo, specify those (and only those) dependencies as
fulfilled that correspond to the current versions of any unpublished API.
Second, versioning of (published) API in general: Lets concentrate on
UNO interface types. There are two ways (apart from the one we use,
adding new interfaces with new names) how the problem of an
evolving/changing interface could be addressed: either by allowing only
compatible changes to an interface, or by also allowing incompatible
changes.
If you only allow compatible changes, you have to identify a list of
potential changes to an interface that actually *are* compatible. From
a client's side, things like adding a new method, or covariantly
changing the signature of a method could be considered compatible. But
from the other side, the implementation of a UNO object supporting that
interface, those changes are definitely not compatible, so if you ever
made such a change to an interface, you would have to be sure to fix all
the corresponding implementations. However, you cannot expect to
control all the relevant implementations (some might be in deployed
extensions), so you cannot make the change. As it turns out, the
concept of compatible evolution of interfaces does not work in (current)
UNO. (You could imagine some drastic changes to UNO, like having
interface types that can only be implemented by certain objects, to make
this possible, though.)
So, you are left with the option of allowing incompatible change: Have
two completely different versions X1 and X2 of some interface X. Now,
you have a design choice: Either allow both versions to co-exist in one
OOo instance, or allow only one version per OOo instance. In the former
case, explicitly labeling the different versions with different
names---as we already do today---is probably the best way to avoid
confusion.
Anyway, I assume the latter case is what people think about when they
request API versioning: Be allowed to change an UNO interface type,
with the consequence that old extensions might no longer work, and have
the system safely detect that some extension will actually no longer
work. This is exactly the situation I described above for unpublished
API: I explained why an automatic mechanism for this is not available,
but also showed that this can be modeled with unpublished API and
judicious use of the dependency feature.
(Promoting this model does have the drawback that it will lead to
extensions that work with some version of OOo but not with later ones,
something that should not have been possible until now, at least not
theoretically in a clean world. After all, you probably can't have your
lunch and eat it too.)
-Stephan
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
