CWS networker specification

Document - ID	Specification Owner	Last Change	Status
	Ingo Schmidt	22.10.03	
Conforms to	
Applies to	
Task ID(s)	#i19265#
Category	Feature

Abstract

In the cws networker we want to create a defined interface between Setup and first Office startup (Setup and SFX). In the first phase we abolish the User-installation. This means that after a network installation, which is the new standard, the user starts directly the Office. The solution in the cws networker is, that the Office starts a hidden User installation using a responsefile.

Alternatively and for compatibility reasons we offer the old user installation using the setup functionality. This guarantees that no functionality will be lost after integration of this cws.

The cws networker does not force the conversion to the native installer. The old setup is still supported.

i-Team Members

	Name	E-mail Address
Specification Owner	Ingo Schmidt (is)	Ingo.Schmidt@Sun.COM
User Experience		
Development	Dirk Völzke	Dirk.Voelzke@Sun.COM
Development	Lars Oppermann	Lars.Oppermann@Sun.COM
Development	Ingo Schmidt (is)	Ingo.Schmidt@Sun.COM
Quality Assurance	Olaf Felka (of)	Olaf.Felka@Sun.COM
Quality Assurance	Jörg Skottke (jsk)	Joerk.Skottke@Sun.COM
Documentation		

Approved for Implementation

	Approved by	Date
User Experience	<Name>	<Date>
Development		
Quality Assurance		
Documentation		
String Review		

Document Change History

Rev. Level	Change	Initials	Date
1.0	Initial release	is	22.10.03

CWS networker:

Changes:

In the CWS networker the following changes have to be done:
The Loader starts the „real“ Setup (packed into the temp directory during installation) always using the parameter „-net“. A standalone installation is no longer available (-> ToDo DV).

Using the setup parameter „-sysint“ makes a user wide Windows systemintegration (-> ToDo DV). Then for instance the Windows startmenu entries are available after the installation. This installation type does not require administrative rights.

Using the setup parameter „-alluser“ makes a system wide Windows systemintegration for all users at the PC (-> ToDo DV). This requires administrative rights.

The systemintegration for Unix is still only user wide and is executed only at the user installation described below. Using neither the parameter „-sysint“ nor „-alluser“ the systemintegration is also for Windows only user wide and executed during the user installation.

The file sversion.ini respectively sversionrc will still be written by the setup due to compatibility reasons, for instance with the testtool. In the cws following the cws networker this file will no longer we written -> announcement (-> ToDo IS).
The destination directory of the user installation can no longer be determined by the user. The default path is (at the moment) %PRODUCTNAME%PRODUCTVERSION (which is resolved for example to „OpenOffice.org1.1.0“) in the user home directory ($SYSUSERCONFIG). All files are copied there at the Office startup on demand.

The path is still written into the sversion.ini (.sversionrc), but the supported bootstrapping file is the bootstrap.ini (bootstraprc). The Office searches the User installation in the directory specified in this bootstrap file. This makes it possible for the user to change the destination of his user installation by editing this entry and to install more than one OpenOffice.org in parallel.

Two types of user installation:

For starting the user installation there are in the future two possibilties:

Directly starting the Setup, which is located in the network installation. Then still appears the known GUI for the user installation. But the dialog, in which the user is asked for the installation path, does not appear, because this path is read from the bootstrap file (-> ToDo DV). The Setup has to pass on this path to the basic scripts and CustomActions, which are executed by the Setup (-> ToDo DV). The language selection dialog in multilingual installations is still required, because for instance the systemintegration is done by scripts, which require the language as parameter. After the user installation there is a user wide systemintegration. From this the Office can be started.

Because the setup offers a systemwide systemintegration for the Windows platform with the parameter „-alluser“ and a user wide systemintegration with the parameter „-sysint“, the user installation needs a changed behaviour concerning the systemintegration. After a network installation with the parameter „-alluser“ (written in instdb.inf) there will never be a user wide systemintegration. After a network installation using „-sysint“ the user installation will always make a user wide systemintegration (-> ToDo DV).

The second method for the user installation is the new method, which has to be propagated in the future. After the network installation the Office is started directly and makes a silent user installation using a responsefile.

Everytime the Office starts, it controls the existence of the user installation in the directory specified in the bootstrap file. If the user data cannot be found they are created on demand with the silent responsefile user installation.

It is not cleary yet, whether the first step in the Office should be a language selection dialog, in which the user can select the language of his user installation (-> ToDo LO/CJ). Alternatively there can be a default mechanism, in which system settings are interpreted. When there is no language selection at the Office startup, there has to be a dialog in the Office application (Tools-> Options) in which the user can change the application language.

After finishing the silent responsfile installation the Office application starts directly (changes in soffice -> ToDo LO, creation of responsefile -> ToDo IS).

Because the Setup was executed hidden, the Office has to show the license file (and the readme-file) at the first Office startup now ( -> ToDo LO).

In this cws networker the Office controls at startup only the existence of the user directory which is determined in the bootstrap file. It does not check, whether this OpenOffice.org user installation is complete.

ToDos of a user installation:

During the user installation in OpenOffice.org 1.1 the user must accept the license file and can read the readme file. He can determine the destination directory in which the setup installs all files containing the flag WORKSTATION. In a multilingual network installation the Setup presents a dialog, in which the user determines the language of the user installation.

The Setup installs all files containing the flag WORKSTATION

The Setup creates empty directories: user/autotext, user/temp, user/autocorr, ...

These two tasks will no longer be done by a setup, that is started from within the Office in the silent responsefile mode. For this special setup behaviour (not to copy files and create directories) a further parameter („-special“) is required, that the Office can start the Setup in this special mode (-> ToDo DV).

Instead of the Setup, these two tasks are done by the Office itself. Before starting the setup in the responsefile mode, it copies the files from the network installation into the user directory and creates empty directories (-> ToDo LO).

The following tasks are done by the normal user installation and by the responsefile user installation:

Creation of shortcuts: setup, soffice, spadmin

These links have still to stay in the user installation. The canonical way to find the Office is: Find the user installation with the sversion.ini, find the links in the user installation and look for their destination. Then you found the Office network installation. Because of compatibility reasons, these links are still required, but will be removed in a future cws -> announcement (-> ToDo IS).

Creation of the file sversion.ini (sversionrc). This file has not the flag WORKSTATION but INSTALL_INFO. This file also has to be supported because of compatibility reasons and will be removed in a future cws -> announcement (-> ToDo IS)

Configuration: Different Config entries with WORKSTATION flag

-> all tasks of the configuration during the user installation have to be checked (-> ToDo LO, CD)

What happens with the UserData dialog? Starting the user installation in silent mode from within the Office, this dialog does no longer appear (-> ToDo DV, CJ)

Additionally part of the user setup without explicit WORKSTATION flag is the Windows systemintegration, consisting of:

Writing entries into the Windows registry (RegistryItems)

Shellnew directory

Fonts registration

Writing entries into the Windows startmenu (Folder and FolderItems)

The Windows systemintegration is already discussed above. It can be done already in the network installation, using the parameter „-sysint“ or „-alluser“. After „-alluser“ the user installation never tries to make a user systemintegration. In all other scenarios the Windows systemintegration during the user installation will not be changed (-> ToDo DV).

Succeeding is a list of all basic scripts and CustomActions that are executed during the user installation. These have to be divided between Setup and first Office startup in further cws (not all in CWS networker). Part of the Setup has to be for instance the system wide systemintegration, which has to be available before the first Office start. Part of the Office startup has to be for instance the migration, because the Setup network installation cannot migrate any user data.

Basic scripts of the user installation:

gid_Procedure_Kill_Plugin_Wrkstn: Deletes empty directories program/addin and

share/autocorr on the user side (-> ToDo DV: Directories with CREATE flag but without WORKSTATION flag must not be created on user side.)

This script shall not be needed in cws networker anymore (ToDo IS). But of course these directories must not be created by mistake (perhaps a ToDo for DV).

gid_Procedure_Rename_Basicdir: renames user/basic to user/__basic_60

(-> problem of migration, script written by AB)

The migration can only be executed by the Office in the future, no longer from the Setup. A network installation cannot migrate the user data. This basic script must therefore be removed (-> ToDo IS).

gid_Procedure_Copy_Readme_File: Copies the readme and license files into the user installation. The readme- and license files shall in the future no longer be copied into the OpenOffice.org directory in the user home directory (because this is not visible for the user, especially if we rename the destination directory to .OpenOffice.org1.1 for Unix). The Office has to show these files. It finds them in the network installation. Therefore also this basic script can be removed (-> ToDo IS).

gid_Procedure_Remove_Readme_File: Deletes the readme and license files at the deinstallation. Because these files are no longer copied in the installation, they do not need to be deleted during deinstallation. Therefore this script can be removed (-> ToDo IS)

gid_Procedure_Start_Regsvrex: Calling regsvrex.exe shlxthdl.dll

This Basic-Skript will not be changed in cws networker. It will be executed during the User-Installation

gid_Procedure_Uninstall_Regsvrex: Calling regsvrex.exe /u shlxthdl.dll at the deinstallation

This Basic-Skript will not be changed in cws networker. It will be executed during the User-Deinstallation

gid_Procedure_Check_Uno_Packages_Workstation: Calling pkgchk.exe -r

MBA discusses with DBO, whether this script is needed at the user installation (-> ToDo MBA)

gid_Procedure_Autostart_Inst: Calling quickstart.exe

This Basic-Skript will not be changed in cws networker. It will be executed during the User-Installation

gid_Procedure_Adabas_Inst: Adabas as FollowUpApplication

This script starts the Adabas FollowUpApplication. This can be solved in cws networker:

user installation started with ./setup: No change.

user installation started with ./soffice: During the Office startup the Adabas installation would be very disturbing. Because the user installation is started with a responsefile, the Adabas module is deselected in this file (-> ToDo IS).

gid_Procedure_Javafilter_Xmergesync_Pword_Reg_Install (from Ireland):

Entries for the Windows registry (contains: GetSetupEnv.IsInstallForAllUser)

gid_Procedure_Javafilter_Xmergesync_Pword_Reg_Uninstall (from Ireland):

Deleting the Windows registry entries at the deinstallation

gid_Procedure_Javafilter_Xmergesync_Pexcel_Reg_Install

gid_Procedure_Javafilter_Xmergesync_Pexcel_Reg_Uninstall

These four Basic-scripts will not be changed in cws networker. It will be executed during the User-Installation

gid_Procedure_Cde_Dtint: Calling dtint (Attention: Language parameter)

gid_Procedure_Cde_Deinstall: Calling dtint -remove at deinstallation

gid_Procedure_Gnome_Install: Calling gnomeint

gid_Procedure_Gnome_Deinstall: Calling gnomeint at deinstallation

gid_Procedure_Kde_Inst_For_Redhat: KDE integration

gid_Procedure_Kde_Create_Links: KDE integration

gid_Procedure_Kde_Remove_Links: KDE deintegration

These seven basic scripts make the Unix systemintegration. They all make a user wide systemintegration and will therefore not be changed in the cws networker.

Difficulties with the basic scripts:

Which language shall these scripts use? If the language selection was done by the Office (starting the user installation with responsefile from within the Office), the selected language has to be passed on from the Office to the basic scripts (-> ToDo LO, DV).

The same with the destination directory because there is no more dialog, in which the user selects this (-> ToDo LO, DV, IS).

CustomActions of the user installation:

gid_Custom_Del for deinstallation

This CustomAction has no GUI. Therefore no changes are needed.

gid_Custom_Usp at Intallation (migration from 6.0 to 7, TPF)

This CustomAction has no GUI. Therefore no changes are needed.

gid_Cust_Mig ( has only Migration flag ? )

This CustomAction has no GUI. Therefore no changes are needed.

gid_Custom_Reg4msdoc

At the user installation started with ./setup (therefore with GUI) nothing will be changed. At the user installation in responsefile mode started from within the Office there have to be defined settings for the MS file type registration in the response file (-> ToDo IS).

gid_Custom_Jvm (Java-Installation, works already on demand concerning to MBA)

At the user installation started with ./setup (therefore with GUI) nothing will be changed. At the user installation in responsefile mode started from within the Office the corresponding value will be set to „InstalledorNone“ (-> ToDo IS).

gid_Custom_Regactivex for the ActiveX control

This CustomAction has no GUI. Therefore no changes are needed.

gid_Custom_Regmimetypes (Unix)

This CustomAction contains references to the links in the user directory. If these links will no longer be created, these CustomAction have to be rewritten. In cws „networker“ the links will not be removed, but in a following cws there has to be a new solution (this will be a ToDo for OBR and TRA).

Deinstallation and repair:

Only the behaviour of the loader will be changed to start the „real“ Setup always with the parameter „-net“. The parameters for deinstallation and repair will not be changed. At the deinstallation of the user installation there will be the problem, that the files in the user directory will not be deleted completely, if the user wants to do so (start of ./setup and selection of „Remove all files“). The setup does not know anything about the files in the user directory, because they were copied from the Office during the Office startup. The solution for this problem ist a basic script, which uses „rm -rf“ to remove the user OpenOffice.org directory. This script must only be executed, if the checkbox „Remove all files“ was checked by the user (-> ToDo DV, IS).

The network installation can still be removed by calling „setup -net“. It still needs to be defined, if in this context the user installation from the calling user also shall be removed. (-> ToDo IS)

ToDos after the CWS networker:

There has to be a system wide systemintegration on Unix (ToDo OBR).

There has to be a new dialog during Windows setup, which offers user wide systemintegration, system wide systemintegration or no systemintegration (ToDo DV).

Can this dialog be used for Unix, too?

A system wide systemintegration for Unix (KDE and Gnome) has to be completely new specified concerning to OBR. This specification is available soonest in Octobre 2003. The existing system wide CDE integration during the network installation will not be affected by the CWS „networker“.

In a future CWS there will be no more sversion.ini (.sversinorc).

In a future CWS the links in the user OpenOffice.org directory will no longer be created (this is important for the CustomAction gid_Custom_Regmimetypes).

Installing more than one OpenOffice.org on a system

It is necessary to edit the bootstrap.ini respectively the bootstraprc after the (default) network installation. This file can be found in the program directory. It includes the path to the user installation, which can be changed. After changing this value, the user installation can be started (by ./setup or in the responsefile mode after ./soffice) and the newly defined user OpenOffice.org directory will be created. Different system integrations for different user installations still cannot be installed next to each other on one system.

Which kinds of system integration will be offered in the future?

With native installers the system integration will be done as follows:

Windows:

Regular installation

During the Setup there is a dialog, in which the user is asked, whether this installation is done for all users at this PC or only for the installing user. Accordingly the system integration happens in HKeyLocalMachine and „Documents and Settings\All Users“ (if the installing user has sufficient rights) or in HKeyCurrentUser and „Documents and Settings\username“.

Administrative installation (parameter /a)

This is only a repackaging of the installation set. All cab files are extracted and the prepared installation set is copied onto a network drive. There is no system integration. Every user afterwards has to start the setup in this restructured installation set and can decide for each module in the setup, that this will be installed to „Run from Source“. This means, that all files stay on the network drive. The system integration is done for the user locally.

Advertising installation (parameter /jm or /ju )

The Advertising installation announces a product, but does not install any files. Most parts of the system integration is done, like the Start menu entries and the file type registration. This happens for all users with the parameter /jm and for one user with the parameter /ju. The Windows Installer service installs the application automatically, if the user or another application calls it. The Advertising is therefore also called the installation on demand.

Unix:

Duty:

First installation of the Office as being root user. Then system wide system integration also as root user. For this different packages (RPM, Solaris-Package) for each supported distribution (Solaris-Sparc, SuSE Linux, Redhat Linux) have to be created. This makes the following scenario possible:

The OpenOffice.org is installed on a network drive. Links to the application are created for instance in /usr/dist/bin, pointing to the OpenOffice.org on the network drive. /usr/dist/bin is mounted to all computers and is included into the path variable. Then it is possible to make a system wide systemintegration as root user with the corresponding RPMs respectively Solaris-Packages, without adapting the path to the OpenOffice.org in the files that make the systemintegration.

ToDo MMP: Clarify the look of the Startmenu

Nice To Have: Installation as non-root

It has to be decided in the future, if we want to support this kind of installation.

OBR does not want to make additional RPMs or Solaris-Packages for this kind of installation. Instead of that scripts shall be created, that use user specific (RPM-) databases or that simply copy the files included into Solaris-Packages (after pkgtrans from streamed packages *.pkg). Then it must be checked whether the shell scripts, that are part of RPMs and Solaris-Packages can be executed without root rights.

For system wide and user wide systemintegration only one RPM respectively Solaris-Package shall be created. OBR wants to create the user wide systemintegration dynamically from the RPM that offers system wide systemintegration -> 90 % identical.

In a OpenOffice.org installation as non-root-user the path to the applications is not part of the path variable (as described above with the links in /usr/dist/bin).

Idea: User calls a script „install“. This installs the OpenOffice.org (rpm –db for Office with its own RPM database) and starts then a system integration RPM, which patches the corresponding files.

Open questions: Do we offer a OpenOffice.org installation as non root user on Unix?

-> Do we offer systemintegration as non root user on Unix?

Important: Inhouse Installation as non root user -> scripts for non root user installations are needed. But shall these scripts be made publicly available?

And how about the installation using the Java installer and a GUI? Is this kind of installation only possible with root rights? Contain the setup modules of the Java installer only RPMs and Solaris-Packages, then the installing user of course has to have root rights.

Local installation from within a network installation:

This kind of installation it not compatible with the native installers. Therefore this functionality will not be supported in the future. Merely using the Windows Installer service it is possible to make a complete local installation from an „administrative installation“ (the „administrative installation“ is after all nothing else than an unpacked installation set).

Ingo Schmidt

2003-08-25T15:49:31

Ingo Schmidt