Switchboard configuration handles need to be extended

[premganz]

This is a serious question as to the fundamental switch board architecture of the spo. The library called ServiceHub acts as a switchboard plugging in multiple librarires which might be configured. However true to the idea of design time configuration, the switchboard might be reconfigured only at DESIGN time, by cooking up a flavour or PROFILE for running the entire suite. Examples are DIFF, CACHE_STORE and so on. The question arises when the list of profile grows to be non linear, what if we need a new model like USE_HTML and combine it with AT and CACHE_STORE? Things get to become more complicated with combinations of say 7 modes leading to a spawn of say 20 or 30 profiles.

Can this be avoided by allowing access to the Switchboard in RUNTIME. allowing callers to set certain flags to the library to variously configure components rather than having to recreate the switchboard once per PROFILE.

[premganz]

It is important to realize the degree of configurability of the switch board is so high that it is not possible to predict what libraries might be plugged in by individual runners. In such case, they are expected to bundle the runtime configuration switches along with the libraries rather than expect some ready to use switches in the switchboard itself. The use of the dynamic proxy in the switchboard as well as of interfaces that plug to specific libraries such as WebContentProvider alleviate this issue. However,if something is needed, the interface is to be updated specifically This specific design change suggestion arose out of the need to couple a RAW HTML mode along with a full range of CACHE functions, such as CACHE STORE , LOCAL and DIFF. It is clear that the cacheing function is a high level configuration at the batch level. However, the use of RAW HTML is a more microscopic control. It may be incorporated into the existing Library Interface that deals with fetching the content. However, it is difficult to configure two methods and enable it to be supported in each implementation of the library. All implementations, for different modes of cacheing would then need to support this. There is an alternate proposal to provide a switch in the Switchboard itself that parametrizes the dynamic proxy and causes it to behave differently for all invocations of a certain method such as "getPageContent" returning say html instead of text. This dynamic configuration of indvidual methods duplicates the control given by allowing pluggable libraries, leading to ambiguity of the due process. In such cases to preserve integrity of control, one can use a different Lib_Core to plug into the switchboard, extending and overriding only one method and it makes sense to be handled at the TEST level.

However, it is not that the Switchboard does not permit setting other libraries at runtime (via interface types in setter methods). The problem we see is that there is needed a more uniform treatment of parity of libraries. While navContainer and Libraries for fetching text are pluggable as objects, the core libraries implementing the core keywords are not. This is where it gets bigotric.

[premganz]

the impl* modules are made into concrete modules which themselves have holders for interface types. The multiple places of configuring the interface typed handlers are henceforth from 1.7.9 disallowed (setters are removed) and all setting of interface typed values might be set only on the impl* modules. The init() method in the servicehub had been cleanedup so that the initialization happens recursively at the impl and each of the plugged in handlers (such as webcontentprovider extends extensibleService). Fixed in 1.7.9

[premganz]

done in 1.7.9 to most extent