Apache OpenOffice (AOO) Bugzilla – Issue 111837
Require restarting OOo before using newly installed extension
Last modified: 2017-05-20 10:48:08 UTC
When an extension is installed, it can be used immediately without restarting OOo. This feature is not always appropriate, because the extension may rely on the OnStartApp event to initialize itself when OOo is started. When the extension is installed to a running OOo, the event is not fired and the state of the extension is inconsistent. There can be a contradiction between allowing extensions to catch events when OOo is started, and allowing the user to add extensions to a running OOo and to use them immediately. The developer of the extension should be able to specify that the newly installed extension can be used only when OOo is restarted. Moreover, if the extension uses global variables, updating the extension while OOo is running completely wipes out the contents of these variables (at least if the extension is written in C++), which isn't a good thing.
Please have a look.
We do not have the "restart-required" feature for good reasons. We want to achieve that all extensions are life-deployable. The "restart-required" feature would be just a workaround for bugs in OOo (or extensions) which prevent proper life deployment. > because the extension may rely on the OnStartApp event to initialize itself > when OOo is started. I see it the other way round. What kind of action should it be that MUST be done exactly upon application startup? Shouldn't an extension always be able to do lazy initialization at any time? > Moreover, if the extension uses global variables, updating Global variables are bad design. Think of multithreading! Go and replace those! Problem solved.
What is the problem with requiring the user to restart OOo to use a newly installed extension ? Issue 88692 seems to acknowledge that it isn't always possible to install an extension and use it without restarting OOo. Besides, forcing the extension developers to implement lazy initialization complicates their task unnecessarily. That's why it is necessary to guarantee that the code that initializes the extension is called before the user can use the extension. If an extension has state, this state can't be stored in local variables. It must be stored globally (and the registry isn't always appropriate). So the problem with multithreading can't be avoided. The simplest way is to use global variables. Btw, are you sure OOo doesn't use global variables ? If it does, this means that it is badly designed.
>What is the problem with requiring the user to restart OOo to use a newly >installed extension ? No problem with this feature in general. The actual problem is that it is a feature OOo currently does not support and someone must find the time to implement it. When it shall be done right, lots of things need to be specified and implemented (extend description.xml, user interface, how to deal with open documents, ...). But hey, we're open source. Do you volunteer? ;-) >Issue 88692 seems to acknowledge that it isn't always possible to install an >extension and use it without restarting OOo. I disagree with the conclusion in this issue. There, a concrete bug in OOo is proposed to be worked around via the restart-feature. Right thing to do about that is to fix the actual bug that new menu items will not appear immediately after extension installation in already opened documents. And there will be no more need for the inconvenient (from users point of view) office restart for this scenario. Cool, one step ahead on the road of user friendliness... >Besides, forcing the extension developers to implement lazy initialization >complicates their task unnecessarily. That's why it is necessary to guarantee >that the code that initializes the extension is called before the user can use >the extension. Again, I don't say that this feature is nonsense, just that it currently has no high priority as we have only limited resources. But wait, why do you prefer developer convenience over user convenience? And the need to restart office after extension installation is PITA for the user, right? >If an extension has state, this state can't be stored in local variables. It >must be stored globally (and the registry isn't always appropriate). So the >problem with multithreading can't be avoided. The simplest way is to use global >variables. Don't see your point here without knowing the actual use case, sorry. Out of curiosity: For what do you use global vars and what exactly are you doing upon office startup? >Btw, are you sure OOo doesn't use global variables ? If it does, this means that >it is badly designed. I know OOo uses global variables (mainly in code more then 15 years old, though) and it is common agreement among OOo developers that this is bad design, yes.
> >What is the problem with requiring the user to restart OOo to use a newly > >installed extension ? > > No problem with this feature in general. In your previous comment, you said you wanted to achieve that all extensions are usable immediately and later, in you last comment, you said restarting is PITA for the user. > The actual problem is that it is a feature OOo currently does not support > and someone must find the time to implement it. When it shall be done > right, lots of things need to be specified and implemented (extend > description.xml, user interface, how to deal with open documents, ...). But > hey, we're open source. Do you volunteer? ;-) I may be wrong, but it doesn't seem so complex to implement : - add a new element in description.xml to require restarting OOo - when the extension is installed, warn that it requires OOo to be restarted to be used - wait until OOo is restarted to activate the files in the extension It seem to me easier to implement correctly than the ability to use extensions without restarting OOo. > >Issue 88692 seems to acknowledge that it isn't always possible to install > > an extension and use it without restarting OOo. > > I disagree with the conclusion in this issue. There, a concrete bug in OOo > is proposed to be worked around via the restart-feature. Right thing to do > about that is to fix the actual bug that new menu items will not appear > immediately after extension installation in already opened documents. And > there will be no more need for the inconvenient (from users point of view) > office restart for this scenario. Cool, one step ahead on the road of user > friendliness... Restarting the program is not so inconvenient when you just have to press a button, as is the case with firefox. > >Besides, forcing the extension developers to implement lazy initialization > >complicates their task unnecessarily. That's why it is necessary to > > guarantee that the code that initializes the extension is called before > > the user can use the extension. > > Again, I don't say that this feature is nonsense, just that it currently > has no high priority as we have only limited resources. > > But wait, why do you prefer developer convenience over user convenience? > And the need to restart office after extension installation is PITA for the > user, right? Developer convenience is necessary if you want developers to create extensions for OOo, which in turn increases user convenience. The current situation is convenient neither for the developers (because it is impossible to do the job correctly), nor for the users (because a newly installed extension doesn't update the UI immediately). > >If an extension has state, this state can't be stored in local variables. > > It must be stored globally (and the registry isn't always appropriate). > > So the problem with multithreading can't be avoided. The simplest way is > > to use global variables. > > Don't see your point here without knowing the actual use case, sorry. > > Out of curiosity: For what do you use global vars and what exactly are you > doing upon office startup? For example, if an extension can be used to translate words, it may need to store in the memory the words the user asked to translate. When OOo exits, the extension stores the words on disk, and when OOo starts, it loads the information from disk into the memory. > >Btw, are you sure OOo doesn't use global variables ? If it does, this > > means that it is badly designed. > > I know OOo uses global variables (mainly in code more then 15 years old, > though) and it is common agreement among OOo developers that this is bad > design, yes. Global variables are used to store global resources, and can't be avoided entirely. They must be used carefully and advisedly.
>> >What is the problem with requiring the user to restart OOo to use a newly >> >installed extension ? >> >> No problem with this feature in general. >In your previous comment, you said you wanted to achieve that all extensions are >usable immediately and later, in you last comment, you said restarting is PITA >for the user. Exactly. Because it is PITA for the user I want to achieve that all extensions are life-deployable and do not need a restart. Nothing wrong or contradictorily with this, IMO - just consistent. >I may be wrong, but it doesn't seem so complex to implement : >- add a new element in description.xml to require restarting OOo >- when the extension is installed, warn that it requires OOo to be restarted to >be used >- wait until OOo is restarted to activate the files in the extension As you are so far with this - you know C++, you know OOo UNO API concepts, you have practice coding for OOo, you even have an idea how to implement the feature: Thus, do you volunteer to implement this feature? At the moment, we don't have the resources for this, because currently we have no demand for this feature. If you need the feature urgently, go ahead and implement it. Just make yourself the owner of this issue and start. This is the true spirit of open source. Otherwise you will have to be just patient... >It seem to me easier to implement correctly than the ability to use extensions >without restarting OOo. Many many features in OOo are already life deployment ready and we are working hard to get better and better. It is not the case that nothing works. Its more the other way round. >The current situation is convenient neither for the developers (because it is >impossible to do the job correctly), nor for the users (because a newly >installed extension doesn't update the UI immediately). First, please don't claim two certain problems as "nothings works for both developers and users". That really hurts. Second, you can do your job correctly(!) by doing lazy initialization. Implement a UNO singleton (an XPropertySet impl. maybe) and fill it with your global data during your lazy init. Once instantiated, the singleton will be alive until OOo exits and can be obtained from Service Manager at any time. No real need for the restart feature here. Just don't be too lazy and even today (OOo 3.2) your users can be happy - without restarting their offices after installation of your extension. Restart feature can make it into 3.4, earliest. Third, the problem with some(! not all) UI parts not updated live is a different story, unrelated to your problem, and must be tackled by fixing the actual problem, not worked around with an office restart.
.
Accepted as feature request, target 3.x
> >I may be wrong, but it doesn't seem so complex to implement : > >- add a new element in description.xml to require restarting OOo > >- when the extension is installed, warn that it requires OOo to be > > restarted to be used > >- wait until OOo is restarted to activate the files in the extension > > As you are so far with this - you know C++, you know OOo UNO API concepts, > you have practice coding for OOo, you even have an idea how to implement > the feature: > > Thus, do you volunteer to implement this feature? Sure. Oracle had net income of only $1.2 billion last quarter. I understand they can't hire a few programmers to work on their product OpenOffice.org. I would be really mean to refuse to work for them for free. ;-) > At the moment, we don't have the resources for this, because currently we > have no demand for this feature. If you need the feature urgently, go ahead > and implement it. Just make yourself the owner of this issue and start. > This is the true spirit of open source. Otherwise you will have to be just > patient... Now you have demand for this feature. BTW, the LanguageTool extension also requires restarting OOo (you can check the home page of the extension), so it isn't true to say there is no demand. > >It seem to me easier to implement correctly than the ability to use > > extensions without restarting OOo. > > Many many features in OOo are already life deployment ready and we are > working hard to get better and better. It is not the case that nothing > works. Its more the other way round. I didn't claim that nothing works. > >The current situation is convenient neither for the developers (because it > > is impossible to do the job correctly), nor for the users (because a > > newly installed extension doesn't update the UI immediately). > > First, please don't claim two certain problems as "nothings works for both > developers and users". That really hurts. Ditto > Second, you can do your job correctly(!) by doing lazy initialization. > Implement a UNO singleton (an XPropertySet impl. maybe) and fill it with > your global data during your lazy init. Once instantiated, the singleton > will be alive until OOo exits and can be obtained from Service Manager at > any time. No real need for the restart feature here. Just don't be too lazy > and even today (OOo 3.2) your users can be happy - without restarting their > offices after installation of your extension. Restart feature can make it > into 3.4, earliest. Maybe, but the solution would be partial (if it ever worked). > Third, the problem with some(! not all) UI parts not updated live is a > different story, unrelated to your problem, and must be tackled by fixing > the actual problem, not worked around with an office restart. I'm affected by this problem too.
It should be easy to understand that a company is putting development resources it pays for first (if not, only?) on the tasks the company has demand for. And it should be easy to understand that a company does not employ new developers if the number of current developers is able to implement the things the company needs. As a matter of fact, Oracle currently has no demand for this feature and Oracle OOo developers currently have not enough "spare" time to implement it. Do you really think that your "arguments" will change this behavior and raise Oracles priority for the restart feature? Again if you need this feature now, go ahead and implement it. If not, wait until somebody else (Oracle?) implements it. >> Third, the problem with some(! not all) UI parts not updated live is a >> different story, unrelated to your problem, and must be tackled by fixing >> the actual problem, not worked around with an office restart. >I'm affected by this problem too. What *exactly* is your problem? >> Second, you can do your job correctly(!) by doing lazy initialization. >> Implement a UNO singleton (an XPropertySet impl. maybe) and fill it with >> your global data during your lazy init. Once instantiated, the singleton >> will be alive until OOo exits and can be obtained from Service Manager at >> any time. No real need for the restart feature here. Just don't be too lazy >> and even today (OOo 3.2) your users can be happy - without restarting their >> offices after installation of your extension. Restart feature can make it >> into 3.4, earliest. >Maybe, but the solution would be partial (if it ever worked). I'm convinced that this will work to get rid off OnStartApp event dependency and global variables. I have no idea why the solution would only be partial. What else is missing? The UI thing you mentioned above, I guess? Anything else?
> It should be easy to understand that a company is > putting development resources it pays for first (if not, only?) on the > tasks the company has demand for. And it should be easy to understand that > a company does not employ new developers if the number of current > developers is able to implement the things the company needs. As a matter > of fact, Oracle currently has no demand for this feature and Oracle OOo > developers currently have not enough "spare" time to implement it. Do you > really think that your "arguments" will change this behavior and raise > Oracles priority for the restart feature? Of course not, but I would be very interested to know how Oracle determines whether there is demand for a feature or not. If everybody thought like Oracle, there would be no Linux, no KDE, no Gnome, etc. Aren't you worried that Oracle/Sun failed to build a strong developer community around OOo? How can you ask people to work for free on OOo, while Oracle doesn't show a strong eagerness to make it a better product? You can't ignore that OOo is affected by a lot of bugs that reduce the usability of the software and that could be fixed more quickly if Oracle accepted to spend a little more money. > Again if you need this feature now, go ahead and implement it. If not, > wait until somebody else (Oracle?) implements it. Even if I did it myself, it would take quite some time (aka money), and it would be released to users only in several months (at best). So, I'll continue to use workarounds. > >> Third, the problem with some(! not all) UI parts not updated live is a > >> different story, unrelated to your problem, and must be tackled by > >> fixing the actual problem, not worked around with an office restart. > > > >I'm affected by this problem too. > > What *exactly* is your problem? The fact that new UI elements aren't added immediately to existing windows. > >> Second, you can do your job correctly(!) by doing lazy initialization. > >> Implement a UNO singleton (an XPropertySet impl. maybe) and fill it with > >> your global data during your lazy init. Once instantiated, the singleton > >> will be alive until OOo exits and can be obtained from Service Manager > >> at any time. No real need for the restart feature here. Just don't be > >> too lazy and even today (OOo 3.2) your users can be happy - without > >> restarting their offices after installation of your extension. Restart > >> feature can make it into 3.4, earliest. > > > >Maybe, but the solution would be partial (if it ever worked). > > I'm convinced that this will work to get rid off OnStartApp event > dependency and global variables. I have no idea why the solution would only > be partial. What else is missing? The UI thing you mentioned above, I > guess? Anything else? Even if I did it, I wouldn't be able to test it completely, because OOo crashes when I try to update my extension (I tested on two different Windows systems).
Giving up at this point. You don't seem to be open for a solution different from restarting OOo. Bad, but obviously I failed to convince you that you could implement a live deployable extension. And vice versa, you failed to convince me that you actually need the restart feature. > Aren't you worried that Oracle/Sun failed to build a strong developer community around > OOo? You should ask those questions at the respected mailing lists, not in an issue.
Reset assigne to the default "issues@openoffice.apache.org".