On Thu, Jan 24, 2013 at 11:53 AM, Hans Zybura <hzyb...@zybura.com> wrote: >> -----Original Message----- >> From: Jürgen Schmidt [mailto:jogischm...@gmail.com] >> Sent: Wednesday, January 23, 2013 3:22 PM >> To: api@openoffice.apache.org >> Subject: Re: Incompatible change for extensions >> >> On 1/23/13 3:08 PM, Bernard Marcelly wrote: >> > Message de Jürgen Schmidt date 2013-01-23 10:12 : >> >> >> >> exactly and that means a minor code change and a rebuild. If this >> >> kind of cleanup changes are not allowed with a major release than we >> >> do something wrong. You should not forget the benefit for new >> >> developers that we want to reach. A cleaner and better API is much >> >> easier to learn for them. Existing developers will have no trouble >> >> with adapting the changes but all new ones will benefit. >> >> >> > If you were reading real user questions in forums you would be >> > appalled by the low programming level of those wanting to automate >> > tasks, whether in social clubs, small businesses, administrations and >> > even big companies. They are often non-programmers, or young trainees, >> > that create applications that become indispensable. Don't suppose that >> > they have time and knowledge to quickly debug a program that used to >> > work for months or years. It will be hard for them to find out which >> > change happened in the API and how to modify. >> >> if they are not maintained or if the code is not available anymore it's > more a >> question of time until they won't work. They probably work more by luck. >> >> > >> > If you think that these changes will make the API easier, you are wrong. >> > OpenOffice API is and will remain huge and complex for the casual >> > programmer, because it was created by highly qualified programmers, to >> > be understood and used by their peers; contrary to VBA that is >> > customer oriented. >> >> yes I believe that these are minor step towards better APIs. If we would >> have the power and resources to change many old style services into new >> ones with supporting multiple inheritance interfaces many API could be >> simplified a lot. >> And I think we have to start to do this stuff and major release can be > used for >> this kind of changes. >> >> > >> >> On 1/23/13 9:36 AM, Bernard Marcelly wrote: >> >>> There is not enough good designers; better spend efforts on >> >>> correcting reported real bugs, or on useful improvements (e.g. a >> >>> real integration of Python into OpenOffice, like Basic; or add the >> >>> new dialog controls in the IDE toolbox). >> >> >> >> feel free to join the project and help to improve things like the >> >> Python support, or improving the basic IDE. Remember volunteers are >> >> working on the code base and you can't force them what they should do. >> >> >> >> It's funny that people request and take more than they gave back. >> >> Really if you think certain areas of the program need improvements >> >> please join us and help to improve it. >> >> >> > I know my limits. I don't have the knowledge to modify OpenOffice code >> > and don't like C++ as a language. >> > I can say that I have given back a lot since 2003. Up to now 275 bugs >> > reported; thousands of answers in users-fr, prog-fr mailing-lists, >> > french and english web forums; corrections/improvements in the Wiki >> > Dev'Guide and Basic Programming Guide; a french book of 900 pages >> > demystifying OpenOffice programming; several free tools that help API >> > users. >> > I am not the only one with such background, others have done same in >> > other countries/languages. I am just giving my advice: you are on the >> > wrong path. >> >> I meant really on the development level not the other areas you have >> mentioned. These are of course also very important areas where people >> help a lot to grow the eco system. >> >> Don't get me wrong I appreciate this kind of work a lot. >> >> If we don't change things and improve certain areas over time I will lose > my >> motivation to work on this code. > > I think we all understand this feeling very well. And we surely can all > agree on the fact, that change and improvements are necessary - API included > . The question is: what kind of change at what speed and how disruptive, and > how seriously you are adopting the eco system style of thinking. >
That is a fair comment. I think we all agree that we should not make a disruptive change to the API with only a day's notice. But neither should we say that changes are impossible over a decade. We need something in the middle. The API exists for extension authors, current ones as well as potential future ones. So feedback from them is of course very valuable. I see the logic as: If you must make incompatible changes, do it in a major release. But I don't think the inverse is true: If you make a major release you must make incompatible changes. How much time is required to adapt an extension to API changes? What is fair? A month? A quarter? Look at iOS app authors. A new iOS version comes out and they have updates available a day or two later. OK, they probably get technical information in advance from Apple. But that is why we have this list, to coordinate such changes. I also like the idea of marking a function as deprecated, maybe even supporting the new and old together for a release, to give time for transition. -Rob > Let's calmly sit back, forget release 4.0 for a moment, and think again. > > From your and Ariel Constenla-Haile's arguments I get the following > impressions: > > 1. Indisputable, the API is messy. The real, fundamental problem is that > nobody has a long time agenda for dealing with this messiness. The problems > are seemingly overwhelming. That I can understand very well. What you mainly > seem to have at the moment is the feeling: 'We are planning for a major > release, this is a chance to start doing something'. > > 2. So you - also quite understandably - think of 'starting with easy > things'. (Unfortunately, the first result of this path is a fix to a nearly > none existing 'problem', which is ridiculous with regard to > cost-benefit-relations, as both Bernhard Marcelly and I have tried to > explain in great detail. What both of you still don't understand.) > > 3. Answering critique, you take a stance like 'We do the work, we decide'. > And furthermore 'We will introduce many more - and much more serious - > incompatible changes, because a major release is the only chance to do > this'. The first answer is obviously expressing weakness, not strength - and > both of the answers are very unwise with regard to the POV of 'eco system'. > > 4. We extension developers, on the other hand, are not able to solve the > fundamental problem (mentioned in 1. above) or even contribute to a solution > on any level of API design and/or coding. > > 5. How we extension developers *can* contribute is by making clear the > negative consequences of lightheartedly introducing incompatible changes - > from the POV of our part of the eco system, that is of more or less > experienced extension developers and of the users of our solutions. (Would > you please, please read the respective parts of the thread again and think > about it in earnest, without letting emotions and time pressure get in the > way?) > > 6. The (small) subset of relatively experienced extension developers is > quite able and presumably willing to deal with incompatible changes - when > they are unavoidable and/or worth the cost for the eco system. On the other > hand, a smooth transition, stretching over a long period of time, is always > preferable. In general: let things continue to work instead of breaking > them, but mark the old way as "deprecated", so extension developers have > much more time to follow. Giving extension developers more time to follow is > essential. > > (Yes, I am aware of the fact that this may mean more work for you and even > more rather than less complexity.) > > 7. The path of 'let's start with easy things', making disruptive changes > prior to having a serious long time transition plan worked out, looks very > dangerous to me. The real danger is - aside from the negative > cost-benefit-relation in short term - that this strategy of doing work on > the API will almost certainly be continued, once it is introduced. The > outcome of this would then be that with each major release the majority of > extensions would not work anymore. I am quite sure that this would mean a > really serious blow to the whole project. > > 8. A future where each major release will bring a number of incompatible - > i.e. extension code breaking - changes to the API is just horrendous. In a > scenario like this, I could no longer regard AOO as being a reliable and > valuable platform for my product with respect to maintainability, support, > and customer acquisition. Not only because it would mean too much work for > me (it really would), but because customers simply wouldn't accept the cost > and hassle of updating every other year or so. I have already explained the > reasons for this assessment in my former contribution to this thread. And > I'm sure that every experienced extension developer with a longtime > perspective will share this view. > > Think of this analogy: Our relation to the AOO API partly resembles your > relation to the operating systems. If every major version of Windows, MacOs, > and Linux distributions would seriously break parts of the AOO code base, > would you be able to deal with this? Would users accept the consequences? I > don't think so. - The analogy may not be very strong, but I think you'll get > the gist of the argument. > > Hans > > >> >> Juergen >
