<i>1. Switch STRING type of data to ARRAY to be sent to and from extension.</i>

That wouldn't be of much use. A better solution would be to allow the command to accept:

• string
• number
• bool
• array (containing any of the above)

The DLL would receive the supplied data type as an array of bytes containing the serialized data type, size of this array and the data type identifier. We'd return the favor for the output.

The function signature would then be:
void __stdcall RVExtension(char *output, int outputSize, int outputType, const char *function, const int functionSize, const int functionType)

Of course, we'd then require documentation about how the RV data types work so we can deserialize/serialize them.

If you limit this to arma ARRAY then you do not need any other types as you can pass a single array with:

["string", 23, true, ["string", 23, true]]

Good point, we can just have the command return and take an array. Still, that's not going to make much difference in the difficulty of implementation.

But it will make hell of a difference in ease of using it ;)

What exactly can you put in an extension that you can't do with SQF? I know extensions use C, but I can't think of a reason for what they could supply addon makers with...

1. Switch STRING type of data to ARRAY to be sent to and from extension.

just do "dll" callExtension (str ["hey",3,2.5,["hey2",123]]);
dll could parse that on its own.

2. Should extensions be scheduled or run each in their own thread? Each creates their own problems

<i>just do "dll" callExtension (str ["hey",3,2.5,["hey2",123]]);
dll could parse that on its own.</i>

Yes, but at this point you're essentially writing your own SQF parser.