|
|
Post by Robert on Jun 15, 2023 12:53:37 GMT -5
BTW, if you are concerned about maintaining backward compatibility to prior EFT commands, but would like to simplify this a little more, you could probably change the ;; notation to a single ; semicolon. All that would impact is the parsing for the new options a bit. What you would do is look for one of the new keywords. If you don't find it, the ; just starts a comment and is ignored. If you find one of the keywords, then continue parsing it.
That would give you,
L:**.txt = TXT; DCB EOL LF
I think this is a cleaner and 'nicer' approach.
|
|
|
|
Post by George on Jun 15, 2023 14:41:14 GMT -5
Robert: It would be easier to just pass commands to the normal command processor.
George
|
|
|
|
Post by Robert on Jun 15, 2023 16:20:14 GMT -5
Isn't DCB a normal command? Or do you mean you want to allow any commands? If you want everything, you will need some kind of command delimiter, probably ; right?
|
|
|
|
Post by mueh on Jun 16, 2023 2:15:02 GMT -5
Hi George!
I have a concern moving the DEFAULT and Non-Editable list to EFT that it gets confusing if it conatains info from all instances .
They are now unique for each Instance of SPFLite while there is only one EFT file . ( Unless i missed thomething )
Could you support unique EFT Table in OPT CONFIG the same as you do for SET ?
Thanks
|
|
|
|
Post by George on Jun 16, 2023 9:17:17 GMT -5
MUEH: Making EFT 'Instance unique' is probably possible. I'd have to have look. Might be a bit tricky migrating to it.
Robert: Might as well handle multiple commands, as soon as you restrict it, someone will ask "Why can't I enter an xxxx command?".
George
|
|
|
|
Post by George on Jun 16, 2023 12:30:30 GMT -5
MUEH: Making EFT entries unique to the Instance should be do-able. Existing Instances would start with an empty EFT table, having it inherit the DEFAULT EFT table would be tricky since that's handled normally when the Instance is initially created.. It would need a manual Cut/Paste between Instances to correct this. Would that be acceptable?
George
|
|
|
|
Post by Robert on Jun 16, 2023 12:45:42 GMT -5
This is an interesting discussion. My initial idea did not take into account multiple instances.
I believe the main issue here is the 'lifetime' of the EFT sessions per instance. EFT has been around for a while without too many problems encountered. And, that was with EFT not doing anything extra to support instances.
MUEH, can you give me an example of why you need different defaults in different instances?
Here is my question: If file type ABC is marked as "use DEFAULT" in one instance, but you DON'T want it to be default in the other instance, what is it that you DO want? It seems like it could be either:
(a) Something that just uses a plain profile. If so, the Profile is currently the same in both instances, isn't it?
-or-
(b) Type ABC is marked as use DEFAULT, but there also exists an EFT for it. Currently, EFT takes priority, so if one is present, any 'use DEFAULT' is ignored.
Can you give me an example of where you use both 'use DEFAULT' AND an EFT entry, and where these uses currently work the way you want?
I am having trouble understanding your use case here.
===> George, I just had a thought about all this.
Suppose there were a way to designate ONE instance to be the "Master Instance". Then, any other instance would copy from the master instance whenever any configuration data is not yet defined. That way, you wouldn't have to manually migrate things. And, if a secondary instance were really messed up, you could simply delete it, recreate it, and all setting from the master instance would get re-migrated.
|
|
