On 6/22/11 18:17 , Niclas Hedhman wrote:
Which reminds me; I think EventObjects and EventStore concepts is something we should try to flesh out and put into a 2.0 as well. Your abstraction of "events" as methods is only one possibility. I found it 'odd' because the 'receiver' is known to the 'sender' so to speak, and that is not always the best model. Would be really good to get together for a day to try and solve this.
The "receiver" is a method in an interface. If this is defined by sender or receiver is open really.
One part of the issue is that the EventStore needs to be part of the UnitOfWork scoping and commit.
Yes! So, like we talked about before we need to look at the hooks in before/after commit, and the semantics of that.
I also see that the 'read events' are not required to be within UoW scope, as the events are effectively values, and need a different API and possibly even a different index/query system.
The events are just stored in a log. If you want to index/query, that would be a separate mechanism, which the EventStore could feed. There's an infinite amount of things you might want to do with the events once you have them in the log, but the log is the core.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
