openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Incompatible change for extensions
Date Thu, 24 Jan 2013 20:18:31 GMT
On Thu, Jan 24, 2013 at 11:53 AM, Hans Zybura <hzybura@zybura.com> wrote:
>> -----Original Message-----
>> From: Jürgen Schmidt [mailto:jogischmidt@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
>

Mime
View raw message