Replies: 3 comments
-
I think that's a great idea. I also thought about creating a wiki listing all the extensions that manufacturers have added in their implementation which aren't directly addressed in the Mopria eSCL spec (as it has shown there are quite a lot of such things). In general, all findings could be listed there. The only question is where to do that. It seems most appropriate to either do it in a new repository or in the eSCLKt repo. You could also do it here but it might make the commit history less clean |
Beta Was this translation helpful? Give feedback.
-
Do you like the idea of using the GitHub wiki for this? Or would you rather have it in-source. For the repository I don't have a strong opinion escltk is probably the right spot however. |
Beta Was this translation helpful? Give feedback.
-
I think I will probably create a repository called the-escl-protocol or something in which there are the markdown files which can be compiled to html/pdf/... doc using rustbook and with a CI deploying it to GitHub pages. In this book, there will be all experiences compiled that were acquired from ScanBridge |
Beta Was this translation helpful? Give feedback.
-
I think it would be an interesting contribution to AirScan OSS in general to have a document in this repository, which lists deviations from the AirScan standard.
ScanBridge initially was very conformant to the standard, but more and more changes are introduced to make the app actually functional for a large range of scanners.
Introducing such documentation would show where manufacturers do not implement the standard correctly and which parts of the standard are broken most commonly.
Beta Was this translation helpful? Give feedback.
All reactions