John,
This is just my .02.
The dermination of which site is utlizing which common objects from the Master Site is an issue.
Of course even without any common repository, there was always an issue with $HCIROOT Tcl procs because there was no indication which site they were used in.
It is not as great an issue for us because we have few globally used Tables and almost all of our globally referenced Tcl procs are coded in such a way that they can be driven by arguments and rarely have needed modification.
As a matter of fact, the primary message filtering proc we use here was first released in 1997 and was only modified twice. Once in 1998 and next in 2001.
Both modifications were for additional functionality and were done in such a way that it was not necessary to refresh the in memory version unless one needed to exploit the new functionality. Anyone needing the new functionality would know where they were using it and cause the appropriate refresh.
I have some ideas regarding how identifying the modules to be refreshed and where could be done. One method would involve Cloverleaf modifications and that would be dependent on Healthvision wanting to do that. I think that method is the only valid method.
Of course, one could always include in their integration documentation a section regarding the use of global objects. That unfortunatly introduces additional constaints nit the least of which is the documentation not being kept up to date. After all you need to make a manual effort to set up the soft links so no more work to manually maintain a registry in each site or wherever.
I guess one could entertain writing something that peruses the various object files (NetConfig and Xlates for example) and detect all references to things like Tables, Tcl procs, Variants, etc.; interrogate the directories of the Master Site determining which are global; maintain a registry that could then be queried for a cross reference.
However, many objects can be referenced indirectly (specifically via Tcl) and thus would not show up in the configuration files and thus not in the registry.
At this point, I personally feel the Master Site is better than the Soft Links for the following reasons:
1. The selection of objects shows which are local, in the Master Site, or in Root (this was not there with soft links).
2. Not all Unix facilities will chase down soft links.
3. The future direction of multiple site support in Cloverleaf seems to include the use of the Master Site – not soft links.
4. There is some funtionality I recall (especially in the NetConfig) where if you change an object from local to global (Master Site) by removing it from local the NetConfig automatically recognize that without needing to go an reselect. I am not sure of the details but there seems to be some of that and I expect more of this kind of exploitation will occur in future releases of Cloverleaf(R).
5. There may be others but we have just begun to exploit this feature and this is what I see at this point.
I don’t see us going back to soft links – but I have been wrong before.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
.
