Very, very good feedback IMHO... On Sat, Jan 10, 2009 at 9:17 AM, Jens Schumann <[email protected]> wrote:
> I am not kidding. When I was playing around with Qi4J it felt like writing > the first lines of basic again. And it still feels uncomfortable in certain > areas. Is this a valid fragment? How do I navigate across my domain? How do > I define default state for this entity attribute? ... > > Looks like I am still at the beginning of the steep learning curve;). I think this is highly individual, and possibly even depending on how you went about thinking of your problem domain previously. I would like to compare it to the procedural to OO transition that I myself have been through. I struggled a lot for too long, mainly due to lack of access to information in those days (could well hold true for Qi4j at this moment as well), BUT then one day, out of nothing, it just clicked and the "Ah HA!" moment came and things from then on was a matter of gathering experience. I CAN tell you one thing; Once you have had that moment, it is very hard to go back and write OOP again. :-) > 2.2 Qi4J - the all or nothing approach > > Please correct me if I am wrong: I believe Qi4J can be a good option for a > project that starts from scratch. But once you have a significant investment > in technology that differs from Qi4j it will be very very hard to introduce > Qi4J (and with in COP). > > A simple example: How do I leverage my existing application code base that > uses this large relational database model just like 95% percent of all Java > applications out there? Do I need to throw away my OR mapping and DAO code? > Or maintain Qi4J and traditional access code in parallel? > > "Yes" could be a valid answer, since the COP model could be too different > from the traditional model. But if we say yes .. you know what I am trying > to say. And no, I don't want to discuss RDBMS vs ... again. > > But if we want Qi4J to succeed we definitely need to think about incremental > application migration. And this - in my opinion - includes RDBMS support as > first class citizen. Well, I disagree that Qi4j is an all-or-nothing approach, but we need to get good at explaining transition paths that work, without tossing everything in one go. Again, I see this similar to the procedural-to-OO transition, where you could slowly introduce C++ in your C projects, but eventually all C ended up being converted to C++. > 2.3 Qi4J maturity > Should we better call Qi4J "unstable"? I am not recommending Qi4j for production use until we have reached the goals of, and released, version 1.0. So, yes, it is fairly unstable, but we are getting there fast. The last structural changes, by working with Structure-101, will most probably be the last major incompatible change in the APIs. Some minor stuff may still happen. It is also important to understand that we learn a lot along the way, and as Eric Evans told me, "Take your time to get it right. The world doesn't need another half baked framework." I have a goal that very, very soon, maybe 0.7 release, will split the Qi4j codebase, so that Core, extensions, libraries and so on, all will have their own release cycles. This will both make it more snappy to work with any part, but more importantly force the compatibility in APIs. I also hope that this will trigger engaged individuals to step up and grab a territory of their interest and push that library/extension forward aggressively making it kick-ass. > Yes?! No problem. But then we should jump on my suggestion from part one and > talk more about COP while stating that the only freely available > implementation is still work in progress. Sure, I have no problem with that, just like the Scala guys were modifying the language incompatibly whilst being available to the public for feedback. > 2.4 Focus on solutions > > The list of options in Qi4J lib and Qi4J extension is impressive. What might > be missing are "solutions" that can be extended or improved. What I am > talking about are answers to: > > How do I implement a server application that can be access remotely? > How do I implement a Swing client that talks to my server? Again, good ideas, and we just need more hands. Rickard and I are stretched thin, and although the Core has commit limitations, everything else is open to participation. Just jump right in. One issue here is that "We don't know just yet." still applies to a lot of things. > Same applies for web applications. As far as I know web application support > is not available yet. Initially it might be enough to focus on one solution. > Don't ask me why I think web application support might be the killer > feature;). Ok, this should be fairly simple to implement, both as a client and as a service, at its simplest level. And the topic is large enough to involve auto-generation, publishing and consumption of WSDL as well. Sounds like a cool project for those interested in WS-*. > In general I think it is time to move the focus from "What should we add?" > to "How do I do...?". See "Getting started" in part three for further > comments on this. :-) If you have read the debate in great detail, you should have seen that just about every "We should add..." is driven by a missing answer to "How do I do...". We seldom create constructs that are not backed by a real use-case. And lately, these use-cases (such as Abilities) are discovered when either I or Rickard are trying to apply Qi4j to real projects. > So. This was part two. I have to skip the last, more technical part for now. > Should show up later the day. Excellent feedback, and if you only had the same stamina to help with development work.... ;o) Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
