Closed martinmcclure closed 3 years ago
Perhaps it can use session methods for the extensions. And for that matter load into a new symbol dictionary that can be added to any user's symbol list.
The .gs files reflect the decisions we've made in terms of symbol dictionary allocation in the current Rowan structure. UserGlobals is the default symbol dictionary and when I built the structure I knew that the kernel extensions had to go into Globals and I did not think about the implication of using the default symbol dictionary (UserGlobals) for the non-kernel packages.
I assume that Sparkle and RSR should be loaded as SystemUser, because I assume that the long term plan is that RSR/Sparkle will be part of the base image (loaded into Globals) so that all of the services are available to ALL users of the system ... this implies that we make Globals the default symbol dictionary for Sparkle and RSR.
This decision does mean that Sparkle/RSR developers would need to login as SystemUser to do development, but I don't think that this is the issue, correct?
I've been doing development as SystemUser. We could put Sparkle and RSR into Globals. Long-term I suppose Sparkle and RSR will be packages loadable by Rowan, but will probably be in Globals.
Sounds like a plan ...
The .gs file produced by the solution for #27 put most of the Sparkle code into UserGlobals. The file also contains some extension methods for base classes, which I think means it can only be filed in by SystemUser.
If Sparkle ends up in SystemUser's UserGlobals, then the only user that can use Sparkle would be SystemUser?
Perhaps we should split the extensions into a separate file to be filed in by SystemUser, so the main code can be filed in by any user and then used by that user?
Or suggest another way to make Sparkle usable by ordinary developers?