Thorsten Behrens wrote: > But that's the only safe way to do this, for them. BTW, telling from > past experience here: even if API stays compatible syntactically, > there's absolutely no guarantee that the semantics haven't changed, > and the extensions stops working anyway.
Come on, then why create APIs at all? For the same reasons you could say that no program is usable because it may have bugs. And indeed what you describe is just this: a bug. > I don't see much value in this UNO API compatibility discussion, > unless we deal with this end-to-end. I agree that we shouldn't rush things. I'm not convinced that we have thought hard enough to get the flexibility we (the developers) want without letting our users suffer from the consequences. If we are sure that we must nail extensions to major releases to get the necessary flexibility so be it. But we should try hard to avoid that. What we are doing now has worked for COM developers for a long time. It might not be the most comfortable thing for the developers but IMHO we should try to achieve comfort first for the users, developers second. About COM: you still can take StarOffice 3.0 from 1995 and embed a Writer 3.0 object into an Excel 2003 container. Of course nobody will do that for anything than testing and combining apps with more than 12 years difference in age is an exaggeration. But I hope you get the message. OLE2 is a very complex API that enables a very tight integration. I would be glad if any of our current extensions came close to that. And this complex interaction uses APIs that have been designed more than 12 years ago and have been extended only compatibly until today. Go figure. So it *is* possible to keep compatibility without making an API unusable. Perhaps not always, but that has to be proven. There are a lot of APIs in OOo that are very usable and even if they are not perfect I think we can live with keeping them compatible. There *is* a value in doing so. If you think there are other APIs where this is different then we should try to find a way how extensions can find out at runtime which types of APIs they are using. > An acceptable level of > future-proofness can IMO only be achieved by either QAing against all > extensions (and disabling what hasn't - that's the Mozilla approach), > or running extensions in a sandbox (out-of-process might be good > enough here). That's not exactly the Mozilla approach. Extensions usually are declared as compatible for some releases, mostly until the next major (AFAIK the project explicitly urges them not to declare their extension compatible for the next major). This is wild guessing also. There's no QA involved as you can't QA what has not been released. Only a few extensions are marked comatible only for the current release. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
