On Saturday 10 December 2005 19:20, Stefano Mazzocchi wrote: > Niclas Hedhman wrote:
> > The orthogonality of Cocoon has "died". Noone talks about views. Noone > > highlights the ability to serve same content to many user agents. Noone > > is interested in truly useful smaller components. Noone cares about the > > developer vs designer vs deployer roles. > > Hmmm, interesting, didn't see it this way. I wonder if it's because the > real life forces those role to hybridize over and over, if we didn't > make the right choice in separating them or because really nobody cares. > > If nobody really cares, then I wonder what in hell are we still thinking > in terms of SoC! I think that is purely a matter of "who" is in the studied group. When you started Cocoon, you had the vision to look beyond the developer, and saw that scalability is a problem and went out to create a solution. But, somehow Cocoon didn't manage to reach out to those where this was important, instead it became the geek tool, and that part of the vision eroded. > > I am predicting that the next round of waves will not be around > > delivering HTML or XML to web browsers, AJAX or not. It will center > > around dedicated clients. And not _any_ client - but the Mobile clients. > > I very strongly disagree. Mobiles are getting richer and richer, and the > HTML browser software is becoming more and more commoditized. It might > be easier for everybody to deliver XHTML with Ajax-retrieved CSS and > content than to do it the other way around. Ok, we disagree. Time will show what the future holds. You think the client side will converge over the next 5 years, I say it will diverge a lot, fueled by the inadequacy of HTML and ever higher demanding users, with new set of challenges. > But the important point is not that you can do it, it's all those > borderline cases where you *can'* and, therefore, your complexity starts > to increase dramatically. Agree. > > And this is a lot more interesting to Cocoon than one first realizes. > > 1. Cocoon is already equipped to serve mobile clients, both WML and > > binary formats. No change required. > > Sure, but that's really not that hard to achieve. Really? I take it you are not authoring too many mobile apps atm. The capabilities varies enormously from model to model. Look at the number of JSRs that each model support or not. And that is just the Java world. Then throw in a bunch of other platforms and the mess is complete. > > 2. The most important aspect is the ability to generate media for > > different device models. No change required. > > Pipelines are first class citizens in Cocoon land, but you are talking > to one use of it, one that makes you happy. I'm happy if that happens, > but there are others. The important part is to keep the pipeline > machinery as first class, yet make it easier to use even in other > usecases. See Sylvain's proposal for dynamic and scripted pipelines. Agree. > > 3. Americans have no clue about what is about to happen. Europeans are > > better prepared, and Cocoon is apparently a very European project. > > That's complete bullshit. It is true that multi-modal appeal appears > more in Europe than in the US, A bit of a flame-bait, agreed. But face it, there is no mobile communication culture in the USA to speak of. Will it change? Yes, I am sure, but not over night. Developers also derives from expectations, so where the end-user demand is high, a larger set of development efforts will start. If you don't believe me, you need to go to Japan or Korea. > As I said, cocoon is designed for situations where the number of people > involved, the number of technologies involved, the number of existing > legacy, the number of future complexity is so high that other > technologies don't work. > > Mobile portals? sure, one of them. Banking data interchange? yup. Pharma > and Avionic 1000-pages long manual creation and management? you got > it. Intranets for fortune 500 companies? yup. > > These are all applications where Cocoon has shined. Do you see the pattern? I see the pattern that a very large crowd "out there" thinks Cocoon is not good at anything, perhaps with the exception of pure document publishing. Instead of being known as the framework of "Good enough for everything" it is more known as "Not good enough for anything." The inertia between those two are minute, and all the fancy stuff now being discussed won't change much of that. I have been with Cocoon a long time and "talking my head off" to get others to use it. In a couple of cases, I succeeded, but most of the time not. I have now given up, and don't recommend it for any typical JAWA setup. I don't recommend it where it makes the most sense (large complex organic systems), since I don't feel the vision is there anymore, and don't want to be blamed for bringing in a framework that fell apart due to community entropy. > Cocoon need less people that write email and don't write code, myself > included. :o) Ok, I'll go to the same corner and shut up as well. Sorry for the noise. Cheers Niclas
