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
