To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=66204
------- Additional comments from [EMAIL PROTECTED] Wed Jun 7 07:38:41 -0700 2006 ------- I agree with Oliver here. - The com.sun.star.comp.configuration.backend.PlatformBackend service name is the documented interface for plugging in this kind of functionality. This mechanism is used for several things, which all may or may not be applicable, depending on context or configuration. - Architecturally, this generic service shouldn't contain hardcoded knowledge of the set of desktops for which we happen to have integration services available on certain platforms. That way adding similar support for yet another desktop (XCFE? MS Windows?) would again require modifications to the code. And having another set of contextual circumstances that implies that certain settings should or shouldn't be taken into account would require adding yet another hardcoded condition. - Generally the approach chosen for this service is that plugins (or rather their factories) should figure out if/how they are applicable. Some filtering for efficiency is applied by the system-integration service itself based on supplementary information stored in the service registry. Currently that filtering is only based on SupportedComponents. For the current problem I see the following choices: 1. Every service determines on its own whether it should be loaded. To avoid loading expensive libraries with lots of dependencies, lightweight proxy services can be used that load the real, more heavyweight functionality only after checking applicability. 2. A shared 'desktop integration factory' component acts as a proxy for both versions (and possibly more). It exposes the public UNO component interfaces, but in its implementation checks the current desktop and forwards to the right component for the current environment. This solution is similar to (1.), but with a shared proxy. A possible disadvantage of this solution is that the corresponding "SupportedComponents" list must be a superset of the union of the "SupportedComponents" lists of all supported instantiations. OTOH with a service which we expect to be instantiated at each startup, the loss of lazy instantiation that occurs when SupportedComponents=ALL may be not be a problem after all. 3. A variation of the preceding uses such a proxy factory, which in turn simply fetches a singleton from the context. Thus the code that sets up the UNO component context can be the one that knows how to load the corresponding integration service. In this case the proxy factory has no obvious way to get at the possibly applicable SupportedComponents list, so it probably has to be registered for all components. 4. New filtering capabilities are added to the system integration component. Besides "SupportedComponents", each service registration entry could contain an (optional) "ContextFilter" entry. That filter entry could contain stuff like 'system.desktop-environment="gnome"' and would be evaluated when the service is about to be created (e.g. in BackendRef::getBackend()). This one seems to be the most work. FWIW, I like 1. and 4. the best. - Jörg --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
