Gavin Greenwalt
Well-known member
- Joined
- Dec 29, 2006
- Messages
- 7,614
- Reaction score
- 0
- Points
- 36
- Age
- 40
This would add a couple bytes of overhead but I think it would be worth it for streamlining the API and that is to add an extra field that tells the SDK what kind of data is being received along with the data.
So something like BLIFT could go like:
:F: aka "float"
:H: aka Histogram
:C: aka curve
:A: aka Aperture
:S: e.g. string
etc.
That way you don't need that giant list of explicitly defined matchings in the SDK you could just let the SDK go "Oh this value I just received is a curve data struct". You could add and remove parameters to the SDK then without updating the client side code.
If you took it to the extreme you could also do it like this for a couple more bytes:
:F4:
Aka
"This is a float value, and you should multiply by 10^4 (10,000) to get the correct float value"
Then if I get something like this:
I know oh ok:
So something like BLIFT could go like:
:F: aka "float"
:H: aka Histogram
:C: aka curve
:A: aka Aperture
:S: e.g. string
etc.
That way you don't need that giant list of explicitly defined matchings in the SDK you could just let the SDK go "Oh this value I just received is a curve data struct". You could add and remove parameters to the SDK then without updating the client side code.
If you took it to the extreme you could also do it like this for a couple more bytes:
:F4:
Aka
"This is a float value, and you should multiply by 10^4 (10,000) to get the correct float value"
Then if I get something like this:
Code:
#$DRAGON:C:MAXSHA:360000:F3:I know oh ok:
Code:
maxShutter = (float)[message]/pow(10,3)