Sylvain Wallez pisze: > Grzegorz Kossakowski wrote: >> I guess this e-mail is already long enough to cut it here. If you are >> interested in my ideas on providing functional implementation of >> sitemap (that would be inspired by some characteristics of bash) I >> could write a little bit more on it with some details. >> > > Interesting thoughts, especially as I am myself interested in functional > programming, which I started with Javascript, then learned Erlang and > looked at Scala as a very interesting way to bring those programming > paradigms to the Java platform.
Hi Sylvain. Thanks for your comments. Great integration of Scala with Java is one the most important reasons why I brought Scala into this discussion. For others reading this thread: Scala's code compiles to a binary format understood by JVM so you can use Java code from Scala code and the opposite way. > Now we have to think about what this community is about, and what we can > do to make it successful again. An open source community is a delicate > balance between interest of developers in developing the product, and > interest of users in actually using the product. The concept of > "interest" covers many different aspects: for developers, this includes > a combination of hacking pleasure, pure altruism, strengthening a > business related to the product, socializing with like-minded people, > etc. For users, it includes being able to be efficient and productive, > finding support from developers and other users, and being able to > understand the product to tune it and ultimately write bugfixes and > patches, opening the way to committership. > > The Cocoon community has been a bit special in this regard, since Cocoon > allows to do quite complex stuff with a small amount of "code" (sitemap > and XSLT are code) and without requiring strong programming skills. I > remember someone sending a "Thank you" email, explaining how Cocoon > allowed him to do stuff he wouldn't have been able to do without it, and > thus start a consulting business that allowed him to work from home and > spend more time with his family. How rewarding for us developers! Cocoon > allows less skilled users to _do_ stuff, and skilled developers to be > highly productive. This is why this complex product attracted brillant > innovation but at the same time was more accessible to average people > than less sophisticated products. Yep, that's a great description of Cocoon strengths. The question that comes to my mind is if we still continue to maintain these characteristics? > Looking at our website, I think we have forgotten what forms our > community: "Apache Cocoon is a Spring-based framework (since version 2.2 > of Cocoon) built around the concepts of separation of concerns and > component-based development. Cocoon implements these concepts around the > notion of component pipelines, each component on the pipeline > specializing on a particular operation." Ok, that looks like an answer to the above question. ;-) > Well, Cocoon old-timers understand what it means (at least roughly in my > case, as I never digged into blocks). Now put yourself as a newcomer, > especially a less skilled person representing the largest part of our > users. What the heck is this Cocoon stuff all about? What kind of > problems does it solve? How is it different/better than other products I > can find at Apache and elsewhere? > > Cocoon has been very successful by being a superb integration platform > for everything that can be represented as XML, and there are blocks for > every Apache-compatible library that can produce or consume XML. Even > music, and I've seen people's jaws dropping when I showed them the Bach > prelude being processed in XSLT. Over time blocks have accumulated, the > framework has been abstracted and modularized to become even more > flexible and address even more problems, but this came with a price: > newcomers simply can't grasp what Cocoon is about. > > Also, Cocoon has been an incredible source of innovation, with its > component architecture, the ReSTful sitemap, the mighty (but complex) > portal, server-side scripting, continuations, etc. But the outside world > has also innovated, and new frameworks/techniques have emerged, at all > levels of the stack: Spring as a replacement for Avalon, Wicket for > complex forms, GWT and many others for Ajax, aggregated pages and > portals are now replaced with Ajax gadgets, etc. > > The newer products aren't necessarily easier to use, but are probably > easier to grasp because they do less, or have more introductory > material, or are more "standard" (i.e. widely accepted, be it for good > reasons or not). There also has been simpler approaches such as Django, > Ruby on Rails, or the numerous PHP equivalents. > > Coming back to the original proposal, my opinion is that writing Cocoon > in a functional language would be a fun exercise, but nobody would use > it because nobody in this community would understand it. Note that I say > _this_ community, since for example the CouchDB community happily hacks > hard-core functional Erlang. By introduction of flowscript many people from this community (including me) has been, in fact, gently forced to learn that language. Given the fact that flowscript is widely used it looks like it wasn't harmful experience. I would like to see similar route for Scala that is gently introduced and its integration is orthogonal to mainstream implementation. The it would be community's decision if we want to develop and support it. Also, I'm not proposing to rewrite everything into Scala because it does not make any sense to me; at least at this stage. > Also we have to consider that the XML hype is fading away and that the > times of "everything can be represented as XML" are over, for good > reasons or not. Welcome JSON as a replacement to XML for data > interchange, because it's much more lightweight, native in browsers, and > more typed than XML (it has numbers, arrays, maps). > > Considering this, my personal opinion is that XML pipelines still have a > value, but this value has been reduced back to the original goals of > Cocoon: document transformation for multiple presentations. But it's no > more good as the foundation of a whole application since other > techniques and new approaches (esp Ajax and JSON) have made it easier. Our XML pipeline may serialize into JSON. The point is in how we obtain, aggregate and transform the data. For all of this I thing XML is still the best choice. Moreover, the fading hype of XML might be caused by some other subtle fact. Usually an XML document is represented as a rather heavy *tree* of objects. The problem is that imperative languages (like Java) are very bad at processing trees. At least they a way worse than most of functional languages. Processing XML document in Java is painful and boring so it's not so surprising that people look for something easier. Of course this only adds to your arguments. > At least this is my feeling and own experience. At $work we have a > full-ajax portal, and a very simple URL-matching Java library that has > most of the sitemap matching features in a dozen classes, and a > super-lightweight XML pipeline engine to adapt HTML pages for the web or > mobile phones. And we use Wicket for data-intensive backoffice webapps. > > So what does this all mean for our community? What community of users > should we target? The historical community described above, or a new > kind of community? What's in Cocoon to make it appealing to newcomers? > XML pipelines, the sitemap, server-side scripting and continuations. > Cocoon 2.2 has buried them under a huge technical and presentational > complexity. >From your list my personal choice would be: XML Pipelines, Sitemap. With rich clients the need for continuations seems to be fading away. At least I've lost interest in this subject completely. > Cocoon 3 builds on these core values, but is already IMHO too complex by > having more than a dozen different modules. Note that this complexity is > more organizational than technical, but it makes it too difficult for > people to find their way there (that was my case). Also, a complete > rewrite is needed, but at the same time we should not forget all the > technical expertise that has been put in Cocoon over the years (e.g. > cache, work arounds for well-known Xalan quirks, etc) and completely > reinvent the wheel. Difficult exercise. > > I know this mail brings more questions than answers, and Cocoon has to > reinvent itself, both from a technical and a community point of view. > Are we ready for this reinvention? Can a consensus emerge on what it > should be? The answer is ours. As I've expressed I would love to see a reminiscence of Cocoon's "invention corner". We used to be good at it, why not to continue this tradition? > Thanks for reading so far. Thanks for answering. -- Best regards, Grzegorz Kossakowski
