Re: [xwiki-devs] [Proposal] Choosing the default component implementation

On 04/05/2012 12:51 PM, Anca Luca wrote: "...choosing the default between alternative implementations that should all **still be usable by themselves** is not possible" The overrides mechanism allows to change which component will be returned for the "default" hint, but all the others will be invisible. Exactly. For most of the "services" the XWiki platform currently has (storage, cache), we don't have a "default" implementation, but we rely on a kind of factory to lookup the configured default. That is an actual factory class in the case of the cache service, but just more code in the old XWiki.java class for the storage initialization. A standard way of selecting the default means that we'll need less factories, and less code is always a good thing. Now, suppose one of the older components that had only one implementation, "default", gets alternative implementations, and we want to be able to allow more than one to be active in a wiki, and let the administrator decide which one should be considered the default. How can we approach this? The only way is indeed to have multiple hints, but last time I checked this resulted in more than one instance, even for @Singleton implementations.

Another approach is to deprecate the direct dependency declaration and instead introduce a factory that is responsible for selecting the default, but this breaks backwards compatibility. The "I don't care, just give me the default" strategy works as long as the component implementation is self-contained and doesn't involve data communication. Let's take an example, PDF export. Currently the PDF export is only possible via FOP. If we were to convert the current interface + implementation class into a proper component, we'd name it "default", since it's the only one and who needs a factory for only one implementation. People use it and they're happy because it just works. But we might soon add support for export via an office server. Suppose we want either FOP or Office to be usable as the default PDF export implementation. And suppose we'll want to keep both types of export active, so that we can use either one as the implementation for the default export of documents, the FOP implementation for exporting some kinds of documents like scientific articles, and the office connector for generating PDFs for presentations. Using the overrides mechanism we can only have one active at the same time, unless we introduce yet another factory which we can bypass using manual component lookup. If at some point we decide that the office implementation works better, we might consider changing the default implementation for the pdf component. This means that we'll change the hint of the FOP implementation from "default" to "fop", change the hint of the Office implementation from "office" to "default", and our new version of XE works great if people read the installation guide and properly configure the office connector. But what about those that want to upgrade, but are happy with the older FOP implementation and don't want to add support for the office connector? They'll have to use patched versions of the two component implementations where their hints are reverted back to the old values. Easy? No. And even though "default" means "I don't care what the implementation does", here it does matter a lot which implementation you're using. They have different requirements, and it's important to know if the implementation will require an office instance or not. Saying that this won't happen since we're all really careful when designing our components is wishful thinking. We've refactored other more critical pieces of code than providing alternative implementations for a component, so we will find ourselves in situations where we'll have to switch from only one "default" implementation to several. Designing our component manager to make it easy to transition is the right thing to do. Still, my major problem is not about overrides, but about the semantics of "default" (or lack of it). This says nothing about the actual mechanisms behind the implementation, it just reflects the state of that particular component implementation: it's the default at the moment. Not caring what the implementation actually does works only when there is indeed just one possible implementation that is straight-forward. But in most cases, we do rely on another library that does the work for us, and libraries die, better alternatives come along, and changing that internal aspect of the implementation will sometimes be backwards incompatible, or have a different behavior. Sure, it does the same job, but it does it so differently that some will prefer to use the other approach. We have to let users decide which is their "default", and having multiple implementations with the "default" hint but different priorities is not very intuitive. Why not make everything default and remove hints completely if we don't really put any meaning into the hint? And "default" adds another assumption: XWiki Enterprise is the ultimate target. Our defaults are the only ones that matter. As an example, all the *Configuration components have just one "default" implementation, which relies on xwiki.properties, XWiki.XWikiPreferences etc. Doesn't that tie the platform to the XWiki Enterprise wiki? It's not a direct dependency visible at compilation time, it's worse, and invisible assumption about the final runtime. It's certainly not the default for other types of users that want to embed xwiki-commons or xwiki-platform components in a different type of end product. To me this isn't the default configuration, this is the default configuration used by XWiki Enterprise, thus my proposal of using something else as the generic component hint instead of "default". -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs