Re: [platform-update-dev] Config files

[klicnik@xxxxxxxxxx]

Steve, see the attached for some answers 
Please respond to platform-update-dev@xxxxxxxxxxx 
Sent by:        platform-update-dev-admin@xxxxxxxxxxx
To:     platform-update-dev@xxxxxxxxxxx
cc: 
Subject:        [platform-update-dev] Config files



If we were to write a headless eclipse application to execute during a 
product install and invoke the install/update functions, we will also 
require a way to programatically set configuration information and write 
it to config file.  I don't know if such an interface was planned.  In 
general, we'll need a way to create a new configuration file during a 
product install, and we'll need a way to specify its location, or a way to 
retrieve its location. 
<vk>
take a look at 
org.eclipse.core.boot.IPlatformConfiguration
org.eclipse.core.boot.BootLoader.getCurrentPlatformConfiguration()
org.eclipse.core.boot.BootLoader.getPlatformConfiguration(URL)
</vk>

On a multi-user system like Linux, we expect the correct way to work with 
a product configuration is to have a single config file in a read-only 
area of the disk that product launch scripts would pass during eclipse 
launch (such as /opt/eclipse/eclipse -configuration 
/etc/myproduct/config.xml).  This would allow a system admin person to 
keep a common configuration for a product, and product 
installs/additions/updates would be automatically inherited by all users 
when they next launch.  Does this sound correct? 
<vk>
this would work ... but the user cannot make updates.
</vk>

If the above is correct, it would be useful to also allow users to be able 
to extend the default configuration by creating a local config file that 
inherits from the shared one.  I don't mean a simple copy of the file to 
their own home directory, but rather a way for a config file to reference 
another config file, then override/extend the content as personalization. 
Is this a concept that the current design supports?  This would allow 
individual users to customize their settings without detaching themselves 
from the shared updates. 
<vk>
this is a good idea ... will consider this. 
</vk>

On a related point, if there is a shared config file in a read-only area, 
that means only an administrator could execute updates, right?  Will the 
inability for general users to write to this file cause any runtime errors 
or odd behaviour? 
<vk>
if it causes error it will be a defect
</vk>

/-----------
|   Steve Francisco
|   cisco@xxxxxxxxxx
\-----------