|
|
Post by George on Sept 19, 2023 11:29:16 GMT -5
Robert: I don't see how Project buys anything over what Instance support would do. I can't see going this way just to provide another way of grouping a unique set of settings.
Or am I missing something? What would Projects add that Instances can't handle?
George
|
|
|
|
Post by Robert on Sept 19, 2023 12:23:53 GMT -5
As I envision Projects, they are a "lightweight Instance". When you came up with Instances, they seemed to address the kind of needs that users like Stefan run into, where they may need an instance per network node, or something like that. It's as if they were running SPFLite as a multi-user system. When you do that, then yes, Instances are valuable to maintain discrete system settings per user.
For people like me, I never use instances. I see Instances as sort of a 'blunt instrument' to very forcefully separate 'activity regions' (for lack of a better term). I believe for many users, Instances are TOO blunt of an instrument. Imagine you were an MVS shop, and you wanted to isolate the activity of each TSO/SPF user. You COULD dedicate a physical mainframe to each one of them. That would do it, all right, but it would be way too much overkill.
To me, Instances are kind of like that sort of overkill. If I could apply another analogy, if you want separate computational activities in Windows or Linux, you can use a "system process". That is generally thought of as a "heavyweight" activity, because there is a fairly high overhead to switch between processes (also called a 'context switch'). That is something that has been known for a long time. To perform a 'context switch' that had less overhead, you can use 'threads'. And sometimes, even threads are too much overhead, so (in Windows at least) there is the concept of "fibers", which are "very lightweight threads". As the amount of overhead goes down, the amount of inter-task separation and protection go down, too. But, people developing thread- and fiber-based software understand these tradeoffs and are willing to work within them.
My vision of Projects is as a lightweight Instance. It doesn't require discreet SQLite entries for each Project the way that Instances do. It also doesn't require an SPFLite restart to change a Project the way that an Instance does.
Short answer to what have a Project "buys" is simplicity and low overhead. It also buys future flexibility. At the moment, the concept of Projects provides a way to define a common MACLIB definition for a group of related Profiles, and for FM mode where the current MACLIB implementation doesn't appear to apply.
Does this help?
R
|
|
|
|
Post by George on Sept 19, 2023 15:27:02 GMT -5
Robert: No, it doesn't help much. I doubt there are many users who would have more than a small number of "projects". I just don't see closing an SPFLite session and clicking on the icon for a different instance as being more than a 2-3 second interruption, hardly even noticeable.
Your projects idea will insert another 'layer' of settings variables and I don't see that as necessary, nor do I see it as some trivial change. I just did the changes for Profile MACLIB, a single Profile variable, I don't even want to think about some generalized Profile 'any-variable-may-be-overridden-by-a-project-variable' scenario. I did almost that scenario for the EFT Profile overrides, I certainly don't need yet another possible override condition to add to that.
You seem to think that a multi-layered settings hierarchy is simple to cram into an existing application, well it just scares the *** out of me.
You'll have to provide some concrete examples of how this would work, and the benefits it would create, for me to consider this. Right now it's some 'airy-fairy' idea that I just can't grasp.
George
[Added]
Re-reading what you proposed, it comes down to a global Project=name/NONE setting and a matching SET string that, right now, would only contain a MACLIB statement.
And you want the SET definition 'left-open' for any other wonderful overrides you later on decide would be 'nice'. Sounds like I'd be committing to long term trickle of requests to - add "A", add "B" etc. each with their own possible implementation 'wrinkles'. This could be a never ending list of one at a time requests. Totally unappealing.
[/Added]
|
|
|
|
Post by Robert on Sept 20, 2023 11:43:06 GMT -5
George, just a few replies:
1. "what you proposed, it comes down to a global Project=name/NONE setting and a matching SET string that, right now, would only contain a MACLIB statement." Yes, that is correct. I said so in the writeup.
2. 'I want the SET definition left open for future enhancements.' Well yes, of course I do. Don't you want flexibility to add features that don't require massive changes?
3. "Sounds like I'd be committing to long term trickle of requests ..." Sorry, George, but you committed to that 15+ years ago. Every time you make a beta or new release, it's one more 'drop' in the 'trickle stream'. That's the nature of the beast. You're riding the tiger, and only you can decide when to jump off.
Think of it this way. A number of years back, you decided that ISPF/SPFLite had a number of commands that essentially were clones of FIND and CHANGE. Rather than reinventing the wheel, you made a common find/change engine, and allowed individual commands to tap into that engine, by parameterizing their requests to the engine. That means the find/change engine is "open" to future enhancements. If it were not, the power and flexibility within SPFLite would be a fraction of its current self. And, those find/change commands DO end up taking on a seemingly never-ended list of requests. The most recent of which (unless I missed more staff meetings) was the C Q T options for finding within comments and quotes.
Do you regret adding such open-ended flexibility into your find/change engine? I sure don't. So why do you so object to the Project idea being flexible and open-ended?
Yes, right now, what I envisioned only comprises the project-wide MACLIB. But, it's not my job (or yours, really) to try to dictate the future needs and interests of our users. We have seen years of experience that users can come with remarkably creative ways of doing things. Let's not stifle that creativity.
As an example, long ago there was a time when there was no SET feature. All you had was a bunch of configuration settings. Now, look at all the things SET is being used for. And you are, this very moment, adding another use, by accepting the MACLIB concept and using SET to define it. That is the power of defining things to be open-ended. The concept has proved itself over and over. I contend that this will too. Why would you see this as unappealing?
As far as concrete examples, that is fair request. I know from history that your brain is wired best for concrete examples. Let me see what I can come up with.
In closing, I would like to remind you that this is an IDEA. Ideas don't come to life as gift-wrapped with a bow on top. They manifest themselves out of struggle. The struggle to create ideas is not a bad thing, and you shouldn't see it that way. The more struggle, the better the idea is at solving problems and providing value.
Just my 2ยข.
R
|
|
|
|
Post by George on Sept 20, 2023 14:32:20 GMT -5
Robert: Many good points in your note, but I'm still having trouble grasping just what you envisage a "Project" would control.
We have FLISTS, and INSTANCES available to organize things, the only argument you put forth for projects was that it was 'quick to switch' between projects. But as I pointed out, a shutdown of SPFLite and restart in another instance is perhaps 1-2 seconds. And I'm sure an =X and a Dbl-click on another Icon would be faster than typing "PROJECT something" to do a switch.
There must be more to what you want projects to accomplish than just quick-switching. So far I just don't see what we're trying to accomplish with this.
I don't want some open-ended facility where the additions could involve quite extensive changes and I would feel the obligation to do them just because I created the initial framework. As in the latest MACLIB addition, it wasn't a major change, but it wasn't trivial either.
Not knowing what you are thinking of for future expansions of PROJECT leaves me wondering what I'm signing up for if we proceed. I will not go there without some roadmap of what might be coming down the pipe.
George
|
|
|
|
Post by Robert on Sept 21, 2023 9:29:34 GMT -5
Sigh, I just replied and forgot to click Post, I lost it all, retyping ...
You bring up good points about a roadmap. That is a good idea.
I have some workers coming over today to plan an install for a home generator system, so I won't be able to write up the roadmap until this evening. I promise to get this out ASAP.
R
|
|
|
|
Post by Robert on Sept 21, 2023 14:37:04 GMT -5
George,
All right, let me see if I can combine what you wrote with what I had in mind.
In terms of the initial MACLIB issue, let's say at some point you were to separate the active global MACLIB specification from the SPFLite configuration folder specification. That might require another data entry field in the General Tab of the Global Options GUI. (I would recommend you did that.)
Then, if that were done, what would the effect of having a Project be then? It would be like being able to specify INSTANCE as a primary command. If that were possible, "INSTANCE" would basically mean the same thing as "PROJECT". What would that take?
1. I see that creating many desktop icons with -INSTANCE xxx command-line options would not be needed or used any more. Somehow - and this is likely the tricky part - you would need to figure out some way to change the active instance using a primary command. There would only need to be one SPFLite icon on the desktop. (Well, maybe two. I have one for production and one for the current beta, but that's all.)
2. If there were a 'project' that had a common/shared MACLIB specification, that is very little different from the 'global' definition of the active maclib that is defined when the C:\Users\username\Documents\SPFLite\ is specified in the global options GUI.
3. Swapping the current instance might take some clever coding. If it's too hard to do "the hard way", perhaps you could figure out how to shut down SPFLite and restart it "behind the scenes". (Maybe with a hidden, dynamically created batch file, like you do for the RUN command?) You'd need to record all the active editing and FM status, as needed, so that a restart using a different instance would restore the prior operating conditions as much as possible.
4. Somehow, I think there would be a need to be able to specify an instance in terms of modifications to a "base instance", something like how the old "PROFILE USING" worked. Otherwise, if a new Instance were taken as a snapshot of an existing one (like DEFAULT), and then if the base instance values got changed, the snapshot instance would not reflect that.
I think the way that would need to be done is to copy the way the USING worked, so that the dependent INSTANCE would only define values that were overriding the base. And, no, this would not work more than one level.
I know your distain for anything that even remotely sounds like multi-level processing of anything. So, I am not going to dictate an implementation here. I am just trying to explain the PROJECT/INSTANCE concept. Since a project basically would work the same way as an instance, anything that was supported in an instance would be supported in a project, since they would be the same thing.
Now, does this help?
R
|
|
|
|
Post by George on Sept 21, 2023 17:39:02 GMT -5
Robert: No help. Handling Instances is a convoluted juggling dance normally, and it makes the initial 1st execution of SPFLite a nightmare. And you want to somehow make all that dynamic via some PROJECT or INSTANCE command. Forget it.
And you still haven't described just how some 'Project' would differ from a normal SPFLite session. How? In what aspects? I'm still at a loss of what you're trying to gain with all this. What would be different in a 'Project' environment over the normal environment?
George
|
|
|
|
Post by mueh on Sept 22, 2023 3:07:06 GMT -5
Hi ! Just one entry to this discussion .
There are several ways to start an INSTANCE (Project) without creating several DESKTOP icon's .
You can either exetute a BAT file or MACRO to do the START .
Here another suggestion .
execute following SPFLite cmd .
cmd start "" SPFLite2.exe -I A
in case it's to long to type create SET entries like
IA=cmd start "" SPFLite2.exe -I A
ID=cmd start "" SPFLite2.exe -I DEFAULT
all you have to type in as cmd is =IA to START/SWITCHto/CREATE INSTANCE A .
if you want to switch back to DEFAULT INSTANCE enter =ID cmd .
Having INSTANCES in different Process id's is good for stability . Crash effects only one Project . No Storage constraints and fragmentition Problems .
What i recommend are different EFT and Command Retrieve Tables in OPT CON .
Each instance has it's own resources like RECENT File list EFT entries e.t.c . What you keep in mind is that Profiles are shared since they are in SQL DB .
So it's recomend to LOCK the shared used Profiles otherwise if you issue f.e HEX ON all files in other INSTANCE for this profile are OPENED with HEX ON display .
Hope this helps without implementing complex changes .
|
|
|
|
Post by Robert on Sept 22, 2023 14:27:15 GMT -5
George, it's clear I am not making myself understood. I will try one last time to rethink this in a way that will reach you and make sense. If I can't do it after that, it's probably time for me to give up.
Give me a day or two.
R
|
|
|
|
Post by George on Sept 22, 2023 15:18:58 GMT -5
Robert: Fine. It's just I'm not able to 'see' what the benefit of this is. I don't want ideas for how to do it, but what it buys us in new abilities and/or support.
George
|
|
|
|
Post by Robert on Sept 22, 2023 19:06:37 GMT -5
George, I don't believe I can convince you. There's no point in further arguments.
I withdraw my Projects idea.
R
|
|
|
|
Post by George on Sept 23, 2023 9:00:02 GMT -5
Robert: Your call, but I'd still like to have understood the benefits.
George
|
|
|
|
Post by Robert on Sept 23, 2023 9:19:00 GMT -5
I am going to set this aside for today, and try again tomorrow. I made an initial attempt, but it started sounding too argumentative, and I just can't go there, so I didn't finish it. I do actually believe this is something that could be of some use, but I am not in a good place today. This has to be a chill-out day, for mental health reasons.
R
|
|
|
|
Post by George on Sept 23, 2023 9:34:16 GMT -5
Take your time, there's no hurry, we ARE retired.
|
|
