|
While introducing a simple concept for UNO bootstrapping (see my mail in the udk.dev list), i noticed that there is a need for a general bootstrap-argument-passing-mechanism. At the moment we have different locations where some kind of context knowledge for bootstrapping is needed:
Different, but similar concepts are used (e.g. a file with an entry which points to a special directory). First, i would like to unify these concepts and to use one mechanism for bootstrapping. Second, i also would like to be able to configure the bootstrapping via command line arguments or via environment variables (which, for instance, may be set by setsolar). And third, i want not only micro deploy applications but also libraries/subsystems.
All the different mechanisms used to configure any subsystem have something in common, which i would like to call MICRO DEPLOYMENT. Micro Deployment allows an arbitrary component (application/library) to be configured at deployment time. So that some deployment dependent parameters have no to be compiled in.
E.g. a UNO service becomes typically deploied as a shared library. Because it needs some minimal configuration data to work properly, every application which uses the service has to pass this minimal configuration to the service. Using Micro Deployment, this burden vanishes. The installer can create a minimal configuration, which the service will use during runtime. This Micro Deployment is not only usable by shared libraries, but also by executables.
The Micro Deployment should be as flexible and as simple as possible. It is not designed to do some complex stuff during startup. Its api decomposes into three parts:
A mechanism to allow differentiated access to bootstrap arguments at the runtime library (RTL) level is needed.
Bootstrap arguments passed via command line must have a special shape to be distinguishable from other command line arguments:
Here, the bootstrap parameter "UNO_SERVICES" becomes passed as a command line parameter.
The name of the .ini/rc file to use can be overwritten with the 'setIniFileName' function.
It is also possible to use a custom .ini/rc file name. Particulary when using micro deployment for shared libraries, this makes sence.Accessing an executable bootstrap argument:
int main() {
int result = 0;
OUString argValue;
if(Bootstrap::get(
OUString(RTL_CONSTASCII_USTRINGPARAM("aNeededParameter")),
argValue)) {
fprintf(stderr, "found the parameter, doing something...\n");
do_something();
}
else {
fprintf(stderr, "did not find the parameter, dying...\n");
result = -1;
}
return result;
}
Accessing a library bootstrap argument:
int aLibraryFunction() {
OUString libraryFileUrl;
Module::getModuleUrl((void *)aLibraryFunction, libraryFileUrl);
// cut the library extension
iniName = libraryFileUrl.copy(0,
libraryFileUrl.lastIndexOf((sal_Unicode)'.'));
// add the rc file extension
iniName += OUString(RTL_CONSTASCII_USTRINGPARAM(SAL_CONFIGFILE("")));
Bootstrap bootstrap(iniName);
int result = 0;
OUString argValue;
if(bootstrap.getFrom(
OUString(RTL_CONSTASCII_USTRINGPARAM("aNeededParameter")),
argValue))
{
fprintf(stderr, "found the parameter, doing something...\n");
do_something();
}
else {
fprintf(stderr, "did not find the parameter, dying...\n");
result = -1;
}
return result;
}
Values maybe arbitrary unicode strings which have to be encoded using UTF8. A simple argument expansion is supported:
A special bootstrap argument is supported. This argument defines the name of the '.ini/rc' to use for finding bootstrap arguments for executables. The name of the argument is:
This argument can only be used on the command line:
Application arguments are like bootstrap arguments, except, that they are not specifyable via environment variables or ini-files. Application arguments have to be given on the command line and are more like former called command line arguments.
The following two functions give access to application arguments:
The function "rtl_getAppCommandArg" also supports macro expansion as defined for bootstrap arguments.