Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for v1.1 #16

Open
7 tasks
sparkpunkd opened this issue Jul 28, 2016 · 2 comments
Open
7 tasks

Add support for v1.1 #16

sparkpunkd opened this issue Jul 28, 2016 · 2 comments
Assignees

Comments

@sparkpunkd
Copy link
Contributor

sparkpunkd commented Jul 28, 2016

Extend ledger to support proposed changes to support NMOS Discovery and Registration v1.1. New branch veeoneone has been created to track this. Features include:

  • Pagination of results.
  • Structured queries.
  • Extensions of schemas to include multiplexed streams.
  • Carriage of technical stream parameters via the API.
  • Support for HTTPS.
  • Other minor tweaks e.g. add device_id to a flow.
  • Support for unicast DNS.
@sparkpunkd sparkpunkd self-assigned this Jul 28, 2016
@sparkpunkd
Copy link
Contributor Author

Decided that this is too much to chew prior to the Wuppertal workshop. Will focus on bug fixes and getting v1.0 stable.

@sparkpunkd
Copy link
Contributor Author

sparkpunkd commented Aug 24, 2016

I've had a couple of goes at implementing the changes and I'm finding it hard to go from where I am to v1.1. There are a lot of changes to the model and the new deep structure of the JSON schemas is, in my opinion, hard to work with. In particular, the way the model is now defined couples syntax and semantics ... it's difficult to stand away from the schema and see the patterns.

Also, it also does not help that this was my first serious attempt at writing a classic object model in Javascript and I probably went to town. I want to avoid a toxic mix of my implementation being too brittle and the NMOS schema design being tied to some specific implementation choices about a way to do validation.

I need to go and have a think about this one. I was hoping to keep a common object core for v1.0 and v1.1 and change the validation/serialization based on the version number in RESTful path. Is that possible from where I am? Two prototypes thrown away - but that can only be a good thing?!?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant