Open trieloff opened 6 years ago
schemas that have associated events
I am unable to follow this statement.
Also, what kind of events are we talking about. I can understand C~R~UD & move events for resources, is there a 5th event type you have in mind?
Lastly, I am wondering, if there would exist a unified way of subscribing to those events as well?
@trieloff could you add some examples of this, maybe that will make it easier to grasp.
Right now, we have following events in the repository:
The events don't give clear indication what the resources are that they apply to, and for a given resource, it is not possible to find out what events can be expected.
What I would do is to create a list of events for every schema, e.g.
and so on.
Hmm, I think I now follow what you are saying. My 2¢ -
The events don't give clear indication what the resources are that they apply to, and for a given resource, it is not possible to find out what events can be expected.
The entire point of Noun Verb separation was that the nouns and verbs can be mixed and matched as and when use cases arise.
Coming to the point of, documenting what all combinations exist - I am not at all opposed to doing that, however, I am failing to see how an end user would use that information.
It is not as if a single system is implementing all the combinations. Various systems can use schemas for the different resources present in XDM and emit events about those resources. Take for example - the rejected
event which has been crossed out on your list for assets
. However, nothing prevents an activity such as, asset rejected
in the editorial line of work.
Could a better place for documenting these combinations be alongside API documentation, API that allows subscribing to events (noun-verb pair). WDYT?
Aside:
Take for example - the
rejected
event which has been crossed out on your list forassets
. However, nothing prevents an activity such as,asset rejected
in the editorial line of work.
I'd have included rejected
for asset
and content
if we had a corresponding approved
event.
I'd imagine an event system that follows XDM to link to the XDM docs saying: here are the events that I know and over there are the payloads and entities you can expect.
I'd imagine an event system that follows XDM to link to the XDM docs saying: here are the events that I know and over there are the payloads and entities you can expect.
I agree.
how an end user would use that information.
Just this question remains.
how an end user would use that information. Just this question remains.
Imagine a situation like this: a developer wants to build an application that consumes Adobe assets. Searches in Google for "Adobe Asset API", finds this page: https://github.com/adobe/xdm/blob/master/docs/reference/assets/asset.schema.md sees that there is an "updated" event available for assets and decides not to poll assets for changes, but instead to investigate how to consume this updated event.
Let's do it! :)
@theManikJindal what exactly are you committing to here? :)
@rperelma not much, probably just a PR review. :)
@kstreeter this could be a candidate for our schema descriptors: #154
I think this is quite Asset specific. The types of events that can happen on apps(web or mobile) are hard to fully quantify. I do like the idea of keeping this outside the schemas themselves.
It's not asset specific. Almost any entity should be observable. Stuff that happens in visitor interaction is covered by ExperienceEvent, which is outside of the event-based API support.
Looking at #63, I think it makes sense to point out schemas that have associated events. One idea would be to have a
meta:events
property that is an array of URIs. Each URI points to an emittable event schema.@theManikJindal WDYT?