Download data from a Custom HTML Prompt?

That was, IIRC, reading a 110MB file into a local variable, reversing it, and writing it back out again. So KM has no problems handling at least 110MB of data in a variable. You'll have trouble passing that much into a shell script because of the shell's limit on environment variables, but that's another matter altogether.

So I'll ask again -- how much data are you talking about?

Are global variables and local variables subject to different restrictions here? I was running into the issues I described with global variables. At that point in time I was using global KM variables for everything including logs, CSV data. There would be nothing exceeding large there. Honestly, I doubt it consumed more than a few megabytes's worth of text.

If these are global-variable-only issues, then that makes sense to me, but doesn't really help me given you cannot set/get local variables in a HTML javascript environment, which is the context to all of this.

Further to this, I believe I found one of the aforementioned threads where someone was running into this:

@peternlewis replies as follows:

This happens when you run a script (AppleScript, Shell Script, etc).

As you know, the variables are placed into environment variables, with names that start with KMVAR.

However then total space for the environment variables is limited (by an unspecified limit, sigh), and if the total size of the environment variables exceeds this limit, then the script will not run at all (the attempt to start the script will fail). So Keyboard Maestro takes care to ensure that the total size of the environment variables it includes total up to less than around 100k. If the total size of all your variables (which includes non-password variables, local variables and instance variables) exceeds 100k, then the largest of them will be omitted.

The notification in the log is so if that happens to be a variable you really want to access, and it is not there, you have a change of figuring out what is going on.

You can always access larger variables via AppleScript to the Keyboard Maestro Engine as normal.

So no, you don't have to take any action to prevent these log entries and unless you need to use those specific variables in your scripts, you don't need to do anything.

I trust that is clear.

I actually didn't realise until reading this again now that that user did the same thing to get around the issue as what I'm doing (utilising the engine log for parsing large data strings). Unless something's changed, this is still the main method to getting around using KM variables all these years on. Perhaps it's time for a better solution?

Otherwise, I don't know what to tell you. Those were the issues I was running into it. I'm surprised you were able to load 110MB into one after having re-read that thread. KM was fully functional after you did that and when you continued to use KM for other things I'm guessing? No engine log errors?

if you know how to use local/instance variables in javascript in HTML, without the size restriction, I'm all ears.

They probably can -- subject to certain limitations.

Great! I'll take a look.

But it sounds like you want to write data directly to your general user-space, and WebKit simply doesn't allow that (for very good reason!).

Zero issues here as this is for personal use only.

I'm not sure what you're saying here, so let me just say that you can indeed have the JavaScript in a separate .js file, and the CSS in a separate .css file. They just need to be in the same folder as the HTML file, and possibly in subfolders although I haven't tried that.

I will have a go at this.

I see that @Nige_S beat me to the size issue, So you need to get it out of your mind that KM variables are going to limit you.

Again, I don't know what to say. These were issues I was having as a result of using variables. Clearly other people have had issues too.

I respect that you both don't percieve any issues here, and don't see the need for native file read/writing with the prompt action, but I disagree and still advocate that this would be a worthwhile inclusion.