Jürgen, > The change is really easy and no big thing.
Right, the change as such is very small and the benefits are negligible - but the effect is very large. The cost-benefit-relation is near catastrophic. Who will gain? A handful of developers who program extensions that are designed to work in more than one component. Listen to Bernhard Marcelly! He is a very renowned developer of extensions and right about the fact that most extensions are written for only one component. What will be gained? About 3 minutes of time saving. Who will lose? The overwhelming majority of extension developers, their users and/or customers, and the reputation of OpenOffice in general. Why is this a big thing in the real world, and a bad one? Again, listen to Bernhard Marcelly. Or listen to me. For more than 20 years I make a living out off a successful commercial product for schools and teachers at home that comes as an add-in/extension either for Microsoft Word (VBA, formerly WordBasic) or OpenOffice Writer (StarBasic). My tool is large, it adds about 65 teacher-specific functions to these word processors, it comes with a lot of additional components, documents, fonts, etc.. So I, too, know what I'm talking about. And moreover I have to deal with complex mixed system and office environments in schools and among their teachers. 1. Users Schools and teachers are mostly inexperienced users. Therefore many of them like to stick to working systems, they are certainly not at the front of technological change. Backwards compatibility is an absolute must, where you have to deal with a user scenario like this. My product is currently compatible with Microsoft Word 2000 to 2010 and OpenOffice Writer 3.0 to 3.4. Your proposed "small" change will break backwards compatibility completely. Consider the following example: School "Little Primary School" buys a school license, use at teachers' homes is included, because the main part of lesson preparation is generally done at home. Some teachers are using rather old versions of OpenOffice at home because they don't dare to update, or there are even a lot of old computers at school, where nobody has the time to update. With your proposed change, both I and the person who is responsible at school would have to explain which version of my extension to install on which OpenOffice version. That will literally swamp half of the school's teachers, who often have difficulties to even tell which version of OpenOffice they're using. Believe me, I know my customers! 2. Extension developers a) We extension developers are caught between all stools. Office developers have to write the programming environments for us but generally don't really know what we are doing. Knowing this, even otherwise arrogant Microsoft (Office for Windows department only) always took great care to ensure close connections to VBA developer communities and backwards compatibility for VBA. E.G. parts of our code are very old (1992) and written in WordBasic, but still work perfectly well. On the other hand, Microsoft's Office for Mac department never came to understand the importance of VBA, which resulted in Office for Mac 2008 coming without VBA at all. We decided to develop an alternative, an extension for OpenOffice, which I already had had in mind for some time then. This was really hard and took much longer than I thought, because the learning curve in OpenOffice is unbelievably steep, much more so than with VBA or scripting languages. (BTW, therein lies the problem you should really care about.) What I want to say is: Please don't follow the way of the Office for Mac department at Microsoft, don't be arrogant about the wishes and complaints of extension developers. Listen to Bernhard Marcelly, listen to us! b) Your proposed small change will give a lot of us a lot of headache. Not because of the change as such, but because of a lot of extra work we have to do for a new release, because our users being confronted with more update complexity, and we being confronted with growing need for support. 3. Online update mechanism for extensions Of course this could work, in an ideal world. But how many of the old but still valuable extensions in the repository have it even implemented? Not many, I think. Now, I do have it implemented. But will it really work? I remember the time when I first published the OpenOffice extension of our commercial tool. On Windows systems, which are used by most of our customers, part of our package was a third party tool for license validity checks that made use of the Windows registry. 3 month later OpenOffice 3.3 broke the way, StarBasic in all former OpenOffice versions had given access to the Windows registry, the way that was officially recommended and explained in a sample StarBasic module. How did this happen? Well, it was a fix gone wrong for some data type, something that had never caused a problem before but was thought of as bad design. Please don't fix things that don't cause any problem at all. Let me pose another question in all earnest: Will - after applying your small change to OO 4.0 - a broken extension even be loaded to the point, where the online update mechanism is called? 4. Maintaining extensions over time Jürgen, you recommend to use a max version dependency in extensions. a) I would never do that, because it makes customers angry. And one really doesn't want to make customers angry. When an extension doesn't work anymore, they'll notice and ask for support or whether they need an update. On the other hand, when a message box comes up telling them something along the line that their version of the extension is outdated because they recently updated OpenOffice, they'll complain about unnecessary extra complexity - and rightly so! b) You wrote: "I [...] would do a micro release if I change nothing else". How much work does a micro release for OpenOffice mean? Would you want to do a micro release just because OpenOffice on Windows, MacOS, or Linux had an in-built max version dependency concerning the operating system? I don't think so. This is just a bad fantasy! Please, try to imagine what an otherwise totally unnecessary micro release means for us extension developers, for our customers, for support. You seem to assume that extensions are rather simple things. This is wrong, in my case it would take a lot of work, too, albeit scaled down to a one man enterprise. I simply don't have the time to make micro releases just because of max version dependencies. Jürgen, OpenOffice is on a stable pathway again, I really used to admire your patience, your objectivity, and your leadership in getting Apache OpenOffice to work. But the reputation of Apache OpenOffice is still small and fragile, at least in the education systems of the German speaking countries, where I know the sentiments very well. E.g. after the failure of Microsoft Office for Mac 2008, my extension has won thousands of users for OpenOffice, in spite of the rather long period of uncertainty of the future for OpenOffice some years ago. I fear to lose them again - not so much for me, because I have an alternative Microsoft Office add-in, but for OpenOffice in general. An incompatible change for gaining nearly nothing and losing very much is just a bad idea! Kind regards, Hans Zybura Hans Zybura Software Waldquellenweg 52 33649 Bielefeld Fon: +49-(0)521-9457-290 Fax: +49-(0)521-9457-292 > -----Original Message----- > From: Juergen Schmidt [mailto:jogischm...@gmail.com] > Sent: Friday, January 18, 2013 7:16 AM > To: api@openoffice.apache.org > Subject: Re: Incompatible change for extensions > > Am Donnerstag, 17. Januar 2013 um 23:19 schrieb Rob Weir: > > On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt > <jogischm...@gmail.com> wrote: > > > On 1/17/13 3:00 PM, Bernard Marcelly wrote: > > > > Message de Jürgen Schmidt date 2013-01-17 13:19 : > > > > > > > > > > I disagree, the old mechanism is a design bug and should be > > > > > resolved. It was always planned to fix this a major release. Now > > > > > with 4.0 we can make such changes and we had long discussions > > > > > about incompatible changes for major releases. Extensions can be > > > > > easy updated and by the way it is always a good idea to add a > > > > > max version dependency and release a new version of your > > > > > extension if you have ensured that it works with the newest > > > > > office version. How many unpublished API's are used in extensions > that can change at any time? > > > > > > > > > > We probably don't have enough time to fix many more design bugs > > > > > in the API for 4.0 but this one is definitely worth the change. > > > > > We will document it and the fix is easy. But for all new > > > > > extensions the usage is much more intuitive and less error prone. > > > > > > > > > > > > > > > > > The current mechanism is not a design bug (because it works), > > > > rather a clumsy design. > > > > > > > > To create a toolbar with the same name in Calc, Draw, Impress, you > have to: > > > > - create one WindowState xcu file > > > > - make 2 copies of this file > > > > - modify one line in each copy > > > > - add entries for these files in the manifest.xml Is this really > > > > complex, error prone ? I don't think so, compared to all other > > > > features of an extension. > > > > > > > > About max version dependency : application developers don't see > > > > the future. It's not possible to know in advance when (and why) an > > > > extension will become incompatible. > > > > > > > > > > > > > exactly and that is the reason why I would today add a max version > > > dependency always. I know 4.0 will be next, I would change the max > > > version dependency to 4.0 after testing that everything works and > > > would do a micro release if I change nothing else. > > > > > > > > > > > In the context of a company that has created a specific extension, > > > > happily used for years, Apache OpenOffice 4.0 will be a bad surprise. > > > > Releasing a new version will be difficult: the original developer > > > > may have gone, or have forgotten the building details of an > > > > extension; a new developer has to learn the syntax of an oxt file, > > > > and find out what has to be changed to make it work again. Costs, > delays. Benefits ? None. > > > > > > > > > > > > > This would be a situation that is always bad. If you use > > > unmaintained code you can run always in such trouble. In this > > > specific case the oxt can be changed easily and the Addon.xcu can be > > > adapted, repackage the oxt and that's it. No real code changes and > > > you don't have to remove any XXXWindowState.xcu if you have one. > > > > > > I would love to have much more time to fix API design bugs or change > > > some bad API's to make the life for developers easier in the future. > > > I was a big fan of compatible API's but learned over time that good > > > API's have to evolve over time. We didn't do that and the API is > > > often not easy to use and to understand in many areas. We can > > > improve a lot here but probably not compatible. I have a mixed > > > feeling about it but believe that it will help us to make the product > > > better > over time. > > > > > > This is an easy change, other API changes that require real code > > > changes will be more difficult to communicate. > > > > > > As long as we communicate and document these kind of changes and > > > provide migration paths we are on a good way I think. We have to look > forward. > > > > > > > > > So speaking of communications... What's the plan? > > > > If we're really going to make incompatible changes, we should probably > > do more than put it in release notes or Bugzilla. It should probably > > go into a blog post, with advance notice and a link to technical > > details. > > > > > > we will document it in the wiki with a detailed migration plan. Once we have > this in place we will reach out to the extension developers. Release notes is > one obvious thing but a detailed blog post another one. We can ask > Sourceforge to spread the new via the extension repo as well. > > > > How many month's notice would be enough? Can some update before a > new > > release? Or would we need to provide a "beta" SDK? > > > > > > we can start the communication asap when we have the docu in the wiki in > place. We don't need necessarily a SDK for this. But the changed samples are > part of the snapshot SDK. > > The change is really easy and no big thing. > > I am planning a blog to talk about extension and the best way to maintain > them over time. > > Juergen > > > > > -Rob > > > > > > > Juergen
