|
|
Post by George on Jul 11, 2019 14:56:01 GMT -5
I've been thinking of our discussions of multiple instances, the TITLE naming, the sometimes need for moving the SPFLite folder, and was wondering if perhaps
a radical change to how all those INI type parameters is handled.
This is all 'blue sky' thinking.
Proposal:
* There would be one single file, always located in the \Documents\SPFLite
folder. It would be some shared update database (e.g. SQLite)
* It would contain everything currently in the SPFLite.INI file.
* It would be able to respond to the -TITLE (or some renamed version of it) to
support multiple complete 'sets' of INI file values. Thus a -TITLE (or
whatever) could invoke totally different collections of INI values. Without a
TITLE command line operand, the 'default' INI set would be used. A previously
unseen TITLE value would start with a copy of the default values.
* One of those INI values would be a BASE variable which would indicate 'where'
the remaining SPFLite folders should be located. Default would be
\Documents\SPFLite\ just like today.
* This could be extended as well to handle the Profile INI files, maybe even the
SET variables, etc., basically dumping all these various setting files into
one common SPFLite.CFG file (or some other name)
I've been playing with SQLite and don't see any serious problems in using it. I'm
sure there will be some, but having a DB that handles multi-instance updates is
certainly a big advantage over the current INI files.
Thoughts?
|
|
|
|
Post by George on Jul 12, 2019 11:04:35 GMT -5
I'm only mentioning SQLIte because our needs are simple. We're only talking simple 2 column tables, there's no need for schema's or anything complicated. We're not going to be redesigning the DB or making it complicated. All we're considering here is replacing the INI files (which are simple 2 column tables) with something else which handles that nicely and provides multi-instance access.
Considering the flood of responses we normally get to asking users for comments, I don't think we'll get any worthwhile feedback. SO we're stuck as usual trying to guess what's wanted. We simply won't get input from users that we can sit back and analyze, we've been doing this too long to hold out much hope of that.
As to software footprint, what's another DLL, a few hundred K? We've all got systems now with gigabytes of storage and terabytes of disk space. My system has 8G memory and no matter how busy I am it never gets above 65% , you've got 16G and I bet you never get above 50%. Software footprint worries are just noise.
George
|
|
|
|
Post by mueh on Jul 12, 2019 12:00:02 GMT -5
Hy !
One Response from me .
I don't like the idea frpm putting info in a Data Base where i have to install a new Product i don't need .
Having no simple Access to Read the info stored into it .
Today i can browse INI Profile and State Data .
I also see no Benefit having one file . I can SYNCHRONIZE or Zip/Unzip Documents\SPFLite Folder with all it's subfolders with one command .
I don't see why you would like to share the INI file by multiple instances .
Data set's for one Project should be opened by one instance on Restart beside of different font size normal screen size and Location .
Thanks
|
|
|
|
Post by George on Jul 12, 2019 12:43:09 GMT -5
MUEH: There's no product to install, just like PCRE is shipped with SPFLite, so would SQLite, it's just another DLL in the SPFLite install folder.
But I hear you and Robert - SQLIte will no longer be mentioned. We can stick with INI files so you can all go poking about in them to your heart's content.
George
|
|
|
|
Post by Jo on Jul 13, 2019 13:17:34 GMT -5
Nice ideas, very sophisticated. Maybe someone will use it, but I think, it's fine as it is now. I don't run another SPFLITE instance, nor do I use another SPFLite.INI file. The location C:\Users\..\Documents\SPFLite is fine, I run a daily save on this directory and subdirs, including STATE you know ;-) - so there is no problem when i have to reset the windows-install. And when using an SSD as C:, fine.
Profiles in .INI-files is a good thing, you can easily read then an even change them, as I did some month ago, when VSAVE died.
I know, you do not recommend, but I did a "FF VSAVE" in the PROFILE directory, then a "C VSAVE SAVE" on each .INI file, and all was fine.
So, for me, I have to thank you for this product and your continuous work. And I like the new FM-Macro support and the IMACRO-idea and there is still something to do on IMACRO ;-) - yes, and this is more important for me.
Jo
|
|
|
|
Post by George on Jul 13, 2019 14:39:05 GMT -5
Two comments:
I'd like to understand why some (like MUEH) feel the need to copy the SPF INI and folder files to run multiple copies. If there are specific problems if this is not done, then state them so we can all figure out the best way to solve them. Running off creating batch files and tools to 'work around' the problems/restrictions may keep things going, but I don't think it is the best answer.
Why the reluctance to storing config data in non-text files. We entrust our most critical data to proprietary files all the time, we store documents in DOC files, numerical data in XCL files, backups in ZIP files, disk image backups, documentation in HnD files etc.
etc. Why this fascination with being able to 'see' everything. All the tools that manage these files are track proven to be reliable, but we cling to our old familiar TXT files.
George
|
|
|
|
Post by George on Jul 14, 2019 11:52:38 GMT -5
Of course users would be able to 'see' and 'edit' the data, just like they do today. There is no need currently for users to externally edit the various SFLite INI files, there wouldn't be in the future either.
All I was suggesting is that the 'back-end' storage of all this info would change to something with some more flexibility, keeping all the same current 'front-ends'.
George
|
|
