Re: [api-dev] extension's max supported OOo version
Andrew Douglas Pitonyak wrote: Not necessarily. My take on dispatch URL's is that they should stay stable also except if we removed the functionality in a newer version. But even in this case the code using it would still work; you just wouldn't get a dispatch for the URL and so the dispatch appears to be disabled, something the extension must be able to handle anyway. So the generic nature of the dispatch API helps to keep the code compatible even if the funtionality behind the dispatch might have been changed or removed. Everything else can be dealt with in the code. How about the associated slot? Does that change between releases? Slot Ids are deprecated. There is no guarantee that they will stay the same or that they even will be available at all. To my knowledge until now they still remain untouched but I wouldn't rely on that in the future. As an example, the new Chart will not support them as the old Chart did. The same could happen if other components or parts of it will be exchanged or for whatever reason we redesign our dispatching code to support new features. 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]
Re: [api-dev] extension's max supported OOo version
Hello Mathias, Alle 08:41, venerdì 23 marzo 2007, Mathias Bauer ha scritto: [] I suppose one can think of more things which contribute to an extension's required environment, but are not guaranteed to be stable over major OOo upgrades. dispatch Url's are probably one of these things. Not necessarily. My take on dispatch URL's is that they should stay stable also except if we removed the functionality in a newer version. But even in this case the code using it would still work; you just wouldn't get a dispatch for the URL and so the dispatch appears to be disabled, something the extension must be able to handle anyway So the generic nature of the dispatch API helps to keep the code compatible even if the funtionality behind the dispatch might have been changed or removed. Everything else can be dealt with in the code. [] Thanks for the clarification. However I've cited dispatch URL's only because I recently had to fix an old macro that stopped to work with ooo2.0 The macro uses the dispatchHelper to open the spell dialog. In ooo1.x the dispatch URL was .uno:Spelling and in ooo2.x it has been changed in .uno:SpellDialog Anyway I've retrieved this info using the macro recorder, so I couldn't say if the URL .uno:SpellDialog was already in ooo1.x Thank you Paolo M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] extension's max supported OOo version
Mathias Bauer wrote: Paolo Mantovani wrote: Hi, Alle 20:20, giovedì 22 marzo 2007, Frank Schönheit - Sun Microsystems Germany ha scritto: Hi Stephan, [...] I suppose one can think of more things which contribute to an extension's required environment, but are not guaranteed to be stable over major OOo upgrades. dispatch Url's are probably one of these things. Not necessarily. My take on dispatch URL's is that they should stay stable also except if we removed the functionality in a newer version. But even in this case the code using it would still work; you just wouldn't get a dispatch for the URL and so the dispatch appears to be disabled, something the extension must be able to handle anyway. So the generic nature of the dispatch API helps to keep the code compatible even if the funtionality behind the dispatch might have been changed or removed. Everything else can be dealt with in the code. I also don't agree that the configuration might urge developers to specify a maxversion. There are easy ways to deal with it as the configuration also is a very generic one and so everything can be handled in the code. In the worst case the extension can quit working explicitly if a certain configuration access fails. But I think Frank has mentioned one point where a maxversion *could* make sense: using unpublished APIs. Changing an API used in an extension can make it incompatible and let it crash. This is unavoidable for the extension developer and can't be handled in the extension code. Ciao, Mathias How about the associated slot? Does that change between releases? -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt My Book: http://www.hentzenwerke.com/catalog/oome.htm Info: http://www.pitonyak.org/oo.php See Also: http://documentation.openoffice.org/HOW_TO/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] extension's max supported OOo version
Paolo Mantovani wrote: Hi, Alle 20:20, giovedì 22 marzo 2007, Frank Schönheit - Sun Microsystems Germany ha scritto: Hi Stephan, [...] I suppose one can think of more things which contribute to an extension's required environment, but are not guaranteed to be stable over major OOo upgrades. dispatch Url's are probably one of these things. Not necessarily. My take on dispatch URL's is that they should stay stable also except if we removed the functionality in a newer version. But even in this case the code using it would still work; you just wouldn't get a dispatch for the URL and so the dispatch appears to be disabled, something the extension must be able to handle anyway. So the generic nature of the dispatch API helps to keep the code compatible even if the funtionality behind the dispatch might have been changed or removed. Everything else can be dealt with in the code. I also don't agree that the configuration might urge developers to specify a maxversion. There are easy ways to deal with it as the configuration also is a very generic one and so everything can be handled in the code. In the worst case the extension can quit working explicitly if a certain configuration access fails. But I think Frank has mentioned one point where a maxversion *could* make sense: using unpublished APIs. Changing an API used in an extension can make it incompatible and let it crash. This is unavoidable for the extension developer and can't be handled in the extension code. 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]
Re: [api-dev] extension's max supported OOo version
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, There is only a min version, see http://udk.openoffice.org/servlets/ReadMsg?list=featuresmsgNo=40. The rationale for not having a max version is that OOo's UNO interface should generally be backward compatible. which implies that UNO extensions can/should not use unpublished API, right? Isn't this is somewhat too strong restriction? Also, the restriction for our configuration isn't as strong as for UNO API, so if an extension expects a certain configuration to work with, and this changes in a future major update of OOo, then the extension will break, too. I suppose one can think of more things which contribute to an extension's required environment, but are not guaranteed to be stable over major OOo upgrades. So: Shouldn't we introduce a max version? The idea was to go with finer grained dependencies: If your extension has a dependency on some foo which can change in future, three things need to be done: 1 Introduce an XML element foo-dependency to be used in extensions' description.xml. 2 Adapt the OOo code to support foo-dependency (and drop that again once foo changes incompatibly). 3 Add foo-dependency to the description.xml of your extension. Of course, this is a chicken-and-egg problem of sorts. For one, your extension will not work in older OOo versions, even if they supported foo the way your extension expects it (because the older OOo versions do not support the foo-dependency). For another, if you want to use features first introduced in OOo X for which nobody bothered to simultaneously add an appropriate dependency to OOo X, you can use the OOo-minimal-version dependency sledgehammer. For a third, it seemed just not feasible to add fine grained dependencies for each and every conceivable situation up front. Maybe, once again, theory clashes with practice... Lesson to take away? When you are writing an extension today (that shall work with OOo 2.3, for example, and working with OOo 2.3 is not the most urgent requirement), and you use some feature of OOo that may change incompatibly in the future, see that the 1--2--3 above gets done (all together in the OOo 2.3 timeframe)! See http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=17677. Just updated http://wiki.services.openoffice.org/wiki/Extensions_packaging. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[api-dev] extension's max supported OOo version (was: [api-dev] external application getting OOo version number)
Hi Stephan, There is only a min version, see http://udk.openoffice.org/servlets/ReadMsg?list=featuresmsgNo=40. The rationale for not having a max version is that OOo's UNO interface should generally be backward compatible. which implies that UNO extensions can/should not use unpublished API, right? Isn't this is somewhat too strong restriction? Also, the restriction for our configuration isn't as strong as for UNO API, so if an extension expects a certain configuration to work with, and this changes in a future major update of OOo, then the extension will break, too. I suppose one can think of more things which contribute to an extension's required environment, but are not guaranteed to be stable over major OOo upgrades. So: Shouldn't we introduce a max version? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] extension's max supported OOo version (was: [api-dev] external application getting OOo version number)
Hi, Alle 20:20, giovedì 22 marzo 2007, Frank Schönheit - Sun Microsystems Germany ha scritto: Hi Stephan, [...] I suppose one can think of more things which contribute to an extension's required environment, but are not guaranteed to be stable over major OOo upgrades. dispatch Url's are probably one of these things. ciao Paolo M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
