Add Data-Type to number_allocations.md

[HDDen]

Added Data-Type range for MeshCore Images codec (range is for small reserve to future versions). Now its implemented in fork of «meshcore_open» and in online demo.

[liamcottle]

Hey there,

I would recommend allocating one ID for the app itself, and then you can internally allocate your own type ids for any other formats you need.

For example, only allocate/request 0x0120 and not 0x0121.
You can use the first byte(s) in your data payload for additional types.

Please see this comment for additional info: #2392 (comment)

[HDDen]

Hello @liamcottle , and thank you for your reply! The thing is, I’m planning this data type to be standalone, not tied to any particular application (such as my own client fork). It’s a codec, and the plan is for it to be available for integration into other applications. Plus, when transmitting an image, every byte counts, so I’d like to allocate as much of the available space as possible to the image encoding itself.

I’m happy to use a single ID, but I’m concerned that in the future, if the format versions change, I’ll have to come up with a workaround to stay within the type’s constraints, which is why I’ve asked for a range ‘just in case’.
Currently, the codec version is encoded using two bits, which allows for four format versions to be identified; one will be occupied by the current implementation straight away, whilst the second already has some rough ideas or plans in place. That leaves a small margin of two versions.

However, if my request conflicts with the current concept of the type registry, then I would ask that one 0x0120 be allocated.

[liamcottle]

Hey there, thanks for the info.

I’m happy to use a single ID, but I’m concerned that in the future, if the format versions change, I’ll have to come up with a workaround to stay within the type’s constraints, which is why I’ve asked for a range ‘just in case’.

As there's limited space for the amount of IDs we can allocate to the world, we would like to be stringent in how many are given out. It's possible for you to have unlimited IDs by using the first byte (or more) of your payload to encode your own types and version information. I would suggest doing this from day one to future proof.

Unfortunately once our pool of available IDs is used up, it's not possible for us to allocate anymore. However, since you have complete control over your own data payload, you can allocate your own, internally.

Please update the PR to only allocate one ID, and I can merge it :)

Treat it as an application ID, rather than a codec type, that way you can use it for any other image codecs, formats or other use cases you have in the future, without us ever having to allocate another ID.

[HDDen]

@liamcottle Hello! Thank you, I’ve done as you said – I’ve reserved one ID and assigned it to the application; I’ll pass the internal data type/format version within this Data-type (0x0120).