> -----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. 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
