1.1 and 1.1.1 compliance #19
Conversation
|
Cool to see. I'll try to have a look over it more in depth tonight, but initial pass looks alright. Figuring out the testing story would be great for sure |
|
Uhg. Apparently "this evening" means, "almost a week from now" - sorry. Thanks for doing the work and working on rounding out the LTI story here. Before considering the Outcomes service, could you open two other pull requests? I'd like to see d6f9fae in one on its own and 1e1cf47, 83a207f and d94559c in another. This will let me merge those with a patch version bump and get it out to more users. |
|
I made those PRs, if you need I can make new one with all of the 1.1/1.1.1 updates after you merge in those two. I'll be a little more responsive this next time, got extremely busy prepping for a product launch. Thanks! |
|
Cool - can we rebase this onto master now and see where we stand? |
|
Yessir, I'll give it a whirl when I get home
|
… service (backwards compatible)
|
Great thanks for doing that - I'll try to look at it before I head to bed |
…ssign the message property from the parameters
… the outcomes service
|
I had some free time this afternoon/evening to implement a test server to handle the testing of outcomes. The test server validates the crpyto, XML structure, and numerical ranges of values. |
|
|
||
| # Generate a unique identifier and apply the version to the header information | ||
| @head.ele 'imsx_version', 'V1.0' | ||
| @head.ele 'imsx_messageIdentifier', uuid.v1() |
There was a problem hiding this comment.
Does the spec call for v1 uuids?
There was a problem hiding this comment.
Nope they're just treated as a unique ID. It could be as simple as a simple increment counter if you wanted it to be. I just went with UUID due to it's widespread use and guarantees.
|
Awesome - it all seems pretty reasonable. Is this going to require a major version bump or just a minor? Either way probably good to bump to |
|
I would consider this a minor bump at the very least - we could probably go with |
See #12. This will keep us fully compatible with 1.0 with fairly minimal code additions. 2.0 will be a completely different beast. A note for the Outcomes service, it is implemented exactly as the implementation guide has it specified and as a result some of the platforms have unexpected behavior (Moodle is a good example, they return the sourcedid as a JSON formatted string and expect you to return the hash attribute). If the platform follows the spec it should work fine.
A side note, I unit tested absolutely everything I possibly could while adding these updates but the outcomes service obviously needs a test bed, for now it does work to spec and I tested it against platforms. It would probably be a good idea down the line to make a test utility that can verify incoming data and present a "fake" server that will respond with the correct responses.