On Mon, Apr 26, 2010 at 5:34 PM, Rickard Öberg <[email protected]> wrote: > On 2010-04-26 16.35, philippe van dyck wrote: >> Rickard& Niclas, are you still on board of this beautiful ship ? >> How are you respective qi4j-based projects going ?
> And yes, we could definitely release 1.0.1 with the latest changes, so we > have a release for that, rather than having to use snapshots. Niclas, what > are your thoughts on that? As Rickard mentioned, I decided to take on employment in large firm, including moving countries and all that follows from that. So, I have been 'exhausted' and not been able to focus any spare time lately. I thought of pushing Qi4j into the organization, but the project I had in mind is far too high-profile to get necessary approvals, and even though I probably could get the bosses to sign-off, I don't want them to get in trouble if something goes south... So, instead of the rewrite I suggested massive refactoring... much easier sell and that is going well. So, a few weekends ago, I implemented the Google AppEngine low-level store, but need additional testing before committing it. Actually done 2 versions, one with the Map store and one with the direct implementation (because I am looking for using type support) and in that came across some minor annoyances, which I may promote to enhancement suggestions later (right now can't recall the details). As for features moving forward in Core, I am looking towards; + Clean up and tightening UnitOfWork semantics. For instance, what happens to an Entity instance after the UnitOfWork is completed? Should we have 'detach' and possibly 'attach' semantics? How can we provide better lazy-loading support for Entitystore implementors? What about the earlier NestedUnitOfWork, can we sort that out? Should we? + History support for Entities. Almost all apps I have ever worked on that use persistence, have had versioned stores. We should create the APIs and SPIs for this support. + Events and remoting. I still think we should have explicit support for event management, both in-JVM as well as remotely. It is probably a fairly broad subject, from events being immutable entities to in-app signaling to cross-app transport/marshalling support. We should provide the APIs/SPIs for messaging and remoting implementations to things like JMS, MQ, CXF, RMI, Google Protocol Buffers and others, so that apps can be fully agnostic to underlying technology. For me these are (in that order) the top 3 "big things" at Core level we definitely should be working towards this year. There are of course bunches of smaller things, like fixing Indexing, make the libraries usable, auth/auth/audit support, documentation (big one), the IDEA support (sad it didn't get further), making Envisage usable as well remotely connectable, serialization of model to minimize start-up times (important in Google AppEngine)... As I am now getting more settled in (don't need to run around and find things in town), I think I can start contributing a little bit again. My other app is waiting for my finish of Google AppEngine ES, and then I will deploy that publicly. I have two other small ideas waiting for some cycles that I also want to implement this year or early next. So, yes, I will continue to use Qi4j just because it makes my programing experience so much more pleasant than the "pojo world". So, to put the question back to you Phil; What do you have in mind of what we should do? Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
