Hi all, Here we go with part 2 from 3.
Part 2: Non-technical feedback 2.1 COP/Qi4J - a new thought paradigm and programming model One of the major issues regarding Qi4J mass adoption could be the different thought paradigm and programming model. It requires - as written in part one - a strong foundation in domain driven design (which requires good OO skills) and a transition to COP. During my tests it took some effort to get used to COP. And I believe - similar to David Leangen - that you have to have a lot of time to understand the implications of certain design decisions. I even had a hard time to find the right names for fragments (interfaces)... Could certain design blueprints help? Do we need design recommendations that help others identify fragments? I don't know. What do you think how much time it will take for the transition from infrastructure based OOP (as seen in Java today) to COP/Qi4J? I would say at least two medium size projects. Does 1 to 1.5 years sound familiar? 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;). 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. 2.3 Qi4J maturity I just tried to compile my Qi4J example from November 2008. Well. After changing almost all Qi4J imports and a few class names it works again. Unfortunately this happened the last 5-6 months every time I looked into my example. I personally believe Qi4J started to stabilize a lot. The changes however tend to break backwards compatibility regularly. Should we better call Qi4J "unstable"? 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. 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? 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;). 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. So. This was part two. I have to skip the last, more technical part for now. Should show up later the day. So far, Jens _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
