tracking change dates for substack

[Dr. Hawkins]

On Sat, Sep 19, 2015 at 11:08 AM, Mark Schonewille <
m.schonewille at economy-x-talk.com> wrote:

> In this case, it would make sense to use separate files. I bet users who
> are in one jurisdiction don't want to load all the stacks for all other
> jurisdictions into memory. So, make the stacks separate files and load only
> the required files into memory. That will allow you to track the change
> dates of each file individually.
>
>
I've thought of that approach, but users won't be getting the stacks, but a
compiled binary.  I've also toyed with stashing the stacks as blobs in the
db, and storing them locally encrypted.  In either event, they won't be
allowed access to forms for states where they're not licensed.

The file structure for the stacks, though, could get maddening.  I
currently have daily development folders, with stacks
dochawkbk150919a.livecode, 150919b.livecode, etc., and a similarly named
lib stack.  Elsewhere is a file containing the name of the most recent
version of each (automatically updated in preopenstack), and new folders
are automagically created when the date opened is newer than the date of
the stack.

I'll end up with insane numbers of files . . . I've also considered
expanding the directory with the names, and only creating newer versions on
stack save, or command, or some such, and dynamically loading regional
stacks when needed.  The more I think of that, the better storing them in a
database sounds :)


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462