Hi, Thanks for roadmap.
How is [1] and [2] related to current org.qi4j.library.eventsourcing library ? ( as I am about to start using it ) Last time I needed to propagate UnitOfWork.resume/pause calls to the entitystore SPI, without nice solution. Is mentioned EventBus going to be used internally by Qi4j runtime to allow such extensions/hooks into qi4j internals ? To comment on [3], can you point me where is multiple-type problem discussed ? Is it just entity store persistence/query problem or is it broader scope problem ? Is EntityComposite going to lose it's main type ( currently first in CompositeDescriptor.types() ) ? thanks, - Tibor On Sun, May 13, 2012 at 1:24 PM, Niclas Hedhman <[email protected]> wrote: > Since I think we are starting to get back on track for a 2.0 release, > I would like to outline the Goals for 2.0 and the road beyond... > > Any change that breaks compatibility should be brought forward now. > > > * Proposal for an Event Store[1] > > * Proposal for Streaming Query[2] > > * Proposal on handling multiple type Composites and its internal storage.[3] > > All of the above is likely to affect the UnitOfWork and Entity Store > SPI. Event Store and Streaming Query will not be added in 2.0, just > ensure that it can be added later without breaking compatibility. > > For 2.0, the main goal is to release about the feature set of today, > lined up for a string of releases with more features later. > > For 2.1, this is where the main new features will be added. The above > are examples. > > For 2.2, I would like to see a serious documentation, samples, FAQ, > tutorials effort, and less on codebase features. > > For 2.3, who knows... ;-) > > > WDYT? > > Oh, you want dates; Can't promise any... My own ambition is 2.0 > somewhere July/Aug. 2.1 end of the year, but not a promise. > > > > [1] I think that Qi4j needs to support Events in its core > functionality with an SPI for hooks into an EventBus. Events should > probably have something similar to Visibility, and for events related > to UnitOfWork they are only forwarded within the current UoW, and > Events with wider visibility are deferred until UoW.complete(). > > [2] Streaming Query; Ability to query an event stream while the events > occur. Similar to, but much more powerful than, Topics on pub/sub > systems. I imagine that we create the an Event Store concept, and > querying that event store will be from some point in time until > another point in time, possibly in the future, and the callback is > continously fed with updates as the events arrives in the Event Store. > I still have not sketched this in details, but I feel it to be fairly > important feature. > > [3] I think the solution will end up being; An Entity has one Identity > and one Value per Mixin Type. I.e. I starting to lean towards > mutability should simply be removed from entity internals, and > atomically replaced per Mixin type. This makes historical stores a lot > easier to deal with, as well as I think it can contain the answer to > the multiple-type problem. This may not be visible from the client > code. Ideas are welcome. There are probably a bunch of consequences > that needs to be figured out as well. > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/6a2pl4j > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
