When a program loads a resource like a font, or an image, the API has it return an int to identify it. This is vestigal from when the system used RPC. The correct thing to do is for the programmer to assign the resource to a slot. For example, load an image and put it in slot #1 (not wait to be told what slot it is in).
Example:
Old:
int nio_load_image(const char *filename);
Function returns an int to use as a handle, but this is really simulated. It does not come from the client. Nio_lib just keeps track of the order called.
New:
void nio_load_image(int, const char *filename);
int tells client what slot to load the image in. That was we insure that image #1 is the same on both client and server and there is no ambiguity.
Dreadnought should send a message back to the nio_lib with a data structure that contains information about that resource that might be useful to the program running.
The program can wait for the return message, or not, depending on the needs of the program.
Logged In: YES
user_id=914661
Originator: YES
Ignore my note in BugID 1614495 on sourceforge. I think I like the old (existing) API is better. The library can manage the resource handles. No need to burden the programmer with this.
The thing that needs to change though, is that the library needs to inform the client of the resource handle to make sure that they stay in sync.
Right now as images are loaded the API returns a sequential number. This number comes from nio_lib, but nio_lib never informs the client of this number. The library just assumes that the client loads the resources in the same order (...display image #3...). There is nothing that makes sure that the client and the server are in sync on this. It works currently, so it is not that big of a deal, but I think it would be cleaner for the future to sent that number down to the client and make sure that the client and the server have the same resource handle for the same resource.