You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the native event system is required for xAPI events as they are representations of the native events. There are numerous issues with the native event stream, for example, events names don't follow a definite convention, the events are not versioned, some events are invalid JSON.
Rather than fixing all these issues, I propose freezing existing events and declaring the native events as a "use at your own risk zone."
We need to produce and ADR proposing this change and cataloging it's implications.
AC:
A merged ADR
Possibly a DEPR ticket
Possibly a proposed issues to allow the xAPI events to function without the native event subsystem.
The text was updated successfully, but these errors were encountered:
e0d
changed the title
Create and ADR for freezing and strangulating the Open edX native event system
Create an ADR for freezing and strangulating the Open edX native event system
May 4, 2022
I think that our way forward here depends a lot on whether we will ever want to support Caliper or other standards. I've been operating on the assumption that Caliper is desirable, and it's largely been implemented beside xAPI, but haven't heard any call from the community for it yet. If we want to support multiple event streams in the future, however, it makes sense to keep the native events and allow for them to be updated / versioned / renamed to convention if changes need to be made to support downstream transformers.
Without Caliper or other event transformers it probably makes sense in the long term to just move to native support for xAPI, but I think the flexibility that we have presently is actually pretty valuable and doesn't force any current operators using native events to change their system.
Yeah, I've probably been insufficiently valuing the value of the native stream for supporting diverse format mappings. It's certainly easier to not remove it. We should probably document this as a decision. If we need a new event, we start with a native event and map from it.
This should be captured well enough in OEP-26 and the existing event documentation to be clear. Currently you cannot create an event in any other format (xAPI / Caliper), only transform existing events to hopefully it's a non-issue for new events.
Currently, the native event system is required for xAPI events as they are representations of the native events. There are numerous issues with the native event stream, for example, events names don't follow a definite convention, the events are not versioned, some events are invalid JSON.
Rather than fixing all these issues, I propose freezing existing events and declaring the native events as a "use at your own risk zone."
We need to produce and ADR proposing this change and cataloging it's implications.
AC:
The text was updated successfully, but these errors were encountered: