On 9/7/08, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Bertrand Delacretaz wrote: > > > > IIUC what you're saying is that you wouldn't want to support reading > > OSGi configurations from text files found in the repository? > > > > That is supported by the Felix fileinstall stuff (IIRC), and we'd like > > to have similar features, that's one reason to support them. > > > > Yes, that's right. > > > > Also, there's currently no easy way for a Sling user to transfer a > > configuration to someone else: if you install some bundles and play > > with their configs from the OSGi console until they work as you'd > > like, the only way to send the configs to someone else is currently to > > do screenshots of the OSGi console. Not nice, error-prone, and that > > console is not very user-friendly at the moment. > > > > Having config files in the repository makes it much easier - one can > > copy a few bundles and configs in a repository folder, play with the > > configs as needed, and then simply copy those files to reproduce the > > behavior in another Sling instance. > > > > Deployment packages are obviously better when we're speaking of > > distributing collection of components that are prepared by a > > developer. The above scenario would provide "sling admnistrators" with > > a similar mechanism, without them needing any tools besides > > jcrinstall. > > > > Supporting configurations in jcrinstall is simple and useful, I dont > > see why we wouldn't do that. > > > > Hmm, ok, rethinking it, I'm not against this. If it's small and simple, > do it. But I don't see the real value. :) > Fiddling with a configuration in the repository does not provide > any means of what configuration options/values are possible. So you > have to have a very deep knowledge of what you're doing. > The web console provides a much better way of playing around with > configurations. sure. afaik, the goal is not to allow modification to the configuration directly on the storage. like you wouldn't mess with the properties files of the filebase config. managing the config would still go through the normal osgi config admin, but the store would be in the repository. this has the big advantage, that everything your application needs, can be stored in the repository (bundles, scripts, content, config) and can be backed-up, replicated, clustered, etc. with repository means. so a sysadmin does not need to backup the filesystem based config separately.
regards, toby
