@Georg
A few assumptions about your application.
1. multiple people aren't writing to metadata simultaneously
2. it's a read-only call to "is there a new version of one of my apps? Where is it?"
If both of those are true then I'd normally actually use a SQLite database and make ODBC calls to it. I wouldn't say that there needs to be a lot of bells and whistles if all you're doing is retrieving meta data. Plus you could do stuff like actually store the addin in the database as well. JMP tables are great for lots of things. But for this specific application, I'd say it's overkill. If it's just a throwaway call that you're going to close as soon as you see if there's a new version, ....
You can still easily script it. Again this wouldn't work well if multiple users are writing at the same time. The big thing is that when JMP opens a CSV it doesn't lock the original file like it does with a JMP table.
Names default to here( 1 );
dt = open("$SAMPLE_DATA\Big Class.jmp");
csv_path = convert file path("$DESKTOP\Big Class.csv");
dt << Save As(csv_path);
close(dt, no save);
dt_csv = open(csv_path);
dt_csv << Add Rows({:name = "Fake", :age = 14, :sex = "F", :height = 14, :weight = 28});
dt_csv:age[1] = 0;
// I can still delete this file even though I have the table open
show(delete file(csv_path));
dt_csv << Save As(csv_path);
I'd just generally go without the JMP table functionality than deal with multiple permissions levels. Because if you open a csv in a JMP script, it opens a JMP table that isn't tied