Redfish EventService Implementation

[Bills, Jason M]

On 6/25/2020 10:26 AM, Brad Bishop wrote:
> One idea floating around to address these is inventing a journal
> metadata scheme that is management interface agnostic.  I understand the
> motivation behind that - it is much simpler for an application to slide
> a single journal entry into the journal with all the metadata needed to
> generate events, than it is for an application to snoop multiple signals
> off dbus and pull events out of that.
> 
> But I wonder if inventing a management interface agnostic scheme for
> adding events to the journal is really just inventing a new data model
> for how we represent things in a server - e.g. are we just working
> around our dbus data model?  Maybe we should fix it instead, so that it
> isn't so difficult for applications to use it?  With that said I don't
> know how to do this and I could use more concrete details on which areas
> of the data model make it hard to consume signals.  Does anyone have any
> ideas or examples?
> 

On this, I think we may want to separate logging vs. eventing both in 
this feature discussion and in the tools we want to use.

When we were talking about logging, I think the journal made sense since 
it is designed for logging and has benefits around that usage.  However, 
I agree that it doesn't seem like the right tool for sending and 
receiving events and signals and that D-Bus sounds like the right tool 
for that.

I think I'm still a little confused at the scope.  My understanding was 
that this initial design for EventService was only for monitoring event 
messages and not resources in general.  It seems like it may not make 
sense to try to use the same tools and approach for both message 
monitoring and resource monitoring?  Do we need to treat them separately 
for now to simplify the discussion?