AMWA-TV / bcp-005-01

AMWA BCP-005-01 NMOS EDID to Receiver Capabilities Mapping
https://specs.amwa.tv/bcp-005-01
Apache License 2.0
3 stars 4 forks source link

Content encoding for binary EDID endpoint #38

Closed prince-chrismc closed 3 years ago

prince-chrismc commented 3 years ago

This is a topic, I'd like to open a discussion on.

There's many ways of making binary easily available, currently we have a raw binary stream.

https://github.com/AMWA-TV/nmos-edid-connection-management/blob/b45c5a7ac75d5c3216d926358c31b0f1ed314118/APIs/EDIDAPI.raml#L114-L122

I'd like to propose using a HEX encoding so it's transport and view.

N-Nagorny commented 3 years ago

@prince-chrismc, could you provide an example please?

prince-chrismc commented 3 years ago

I am thinking something along these lines

/edid: 
   get: 
     description: Returns the raw binary EDID encoded as a hexadecimal as per https://tools.ietf.org/html/rfc1505#section-3.3  
     responses: 
       200: 
         body: 
           application/octet-stream:
             example: "74686973206973206120766572792066616E63792062696E61727920626C6F64206F662065646964"
N-Nagorny commented 3 years ago

Its format is a controversial thing. The most of software for work with EDID works with files in a file system, so the current approach lets users download EDID easily to work with it manually. For automatic handling I don't see any difference between a hex number as text and a binary but for user-written scripts and manual actions the binary representation looks better for me.

prince-chrismc commented 3 years ago

Discussed on the call, there's no value add but introduces an extra step to the User Story 6.