User defined index for Ingestion/API posting

Feature requests
#1

I think a clever idea for Edge would be to implement some form of echo’d user-defined indexing, it doesn’t need to be complicated, just a way for users to define which message is being sent.

For instance, if I were to be sending data to the ingestion service every 30 seconds, but there is a bit of latency and the response time can be off a bit, all the while I might be requesting classification results, making other requests, etc.

Instead of having some iffy code searching for keywords in replies, such as “token,” or what have you, we can just parse out the returned index and pass that through some form of a switch so we can write code to handle specific replies when necessary, for instance, I want to request classification results upon reply of an ingestion post.

This is similar to how the software XPlane does it, when requesting different DREF values from the simulator aircraft, you can specify an index. This index is just echo’d back to us to we can determine successfully WHICH message we are getting a reply for, this way we can do many different operations without needing to wait for a reply in fear of it getting lost.

Maybe I’m just unfamiliar with HTTP and POSTING specs and there is a way to do with through the standard or through edge, but this would be very useful, and likely useful for others in the future.

If there is some reasoning behind why this isn’t a feature, or it couldn’t be either because its useless or I’m ignorant to this atm, please let me know.

#2

Hi @DoitfortheLulz, in HTTP every response is explicitly paired to a request already, so you could implement this client side (we actually do this on in the Studio, f.e. to not rendering UI if another request already came in). What language are you writing this in?

#3

Hey there @janjongboom, thanks for the response as always. You are a tank.

But, I’m writing this in C++, I’m using the Qt IDE, all of my HTTP requests/responses are handled by something called a QNetworkManager, with QNetworkResponse and QNetworkReplies for the messages. The manager allows posting/getting.

I guess I’ll have to look further into how I would accomplish this. I could create a reference to QNetworkManager for each type of message I intend to POST/GET, and therefore the signal that is emitted once it receives a reply would be separate, but I was attempting to encapsulate all the requests and responses through one manager. But there are options!

1 Like