Re: [RF] Chainsaws and Seeds
Antonio Gallardo wrote: dave- wrote: Stefano Mazzocchi wrote: Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... IMHO, it does not matter whether the graphs are right or wrong, I think the web 2..0 movement has transcended the issue in any case. Model Based Architectures and Graphical interfaces have allowed far less technical people access to complex environments. I think, although I am not absolutely positive, that a java/pipeline/sitemap is a better base than perl/python upon which to build such systems. It is for that reason I posted the following 2 visions in another thread: As a first vision, I would like to see cocoon accessible to less technical people. This could be done with elegant simplicity and a graphical interface. Here is a good web 2.0 example http://www.activegrid.com/what/applicationbuilder.php. As a second vision, artifacts created by the graphical interface along with any written code could become the model from which alternative implementation systems might be generated. For example, a model POJO could be implementationally persisted in various ways. dave- Should not be this more a Lepido[1] concern? Yes, it is currently a Lepido concern, but perhaps it should be a general community concern. I think the cocoon community should refocus their vision to a model based architecture (MBA) as the single point to align to. A MBA would allow for concurrent competing implementation possibilities rather than having to choose between them. For example, the model could be implemented as a pure java implementation or as a java./javascript implementation without having to choose between them.. I think Lepido would then refocus toward providing a graphical front end to the model.
Re: [RF] Chainsaws and Seeds
I've been wanting to add my 2 pence since stefano's is cocoon
redundant thread. I also admit i'm not a cocoon developer.
Nice charts.. They assume that the same folk that are there at the
start of the start line are the same folk that are end or even perhaps
middle. Despite having a lot of respect for stefano's achievements and
the contribution that cocoon has made, I think the graphs are wrong,
or at least fail to account for iterations of staff turnover.
In the case of a strong SOC approach vs embedding stuff in htmls
(including taglibs), I think whoever that the graphs work as a
concept. As long and no crack addicts wrote the orginal xsl's etc, any
new folk or contractors can fall into line see whats going on and
hence cost of ownership could indeed be reduced.
Seeing that everyone seems to agree that cocoon's strength are the
pipelines, consider the following
c:import var=xmlds uri=mydatasource.xml
c:import var=htmlRenderer uri=/WEB-INF/xsl/html/foo.xsl /
x:transform xsl=${htmlRenderer} xml=${xmlds} /
or even a i18n example
myxmlfmt:message key=mykey //myxml
This is a over simplification and I know that cocoon does a lot more,
but I think that leveraging standard kit (when it works) would make
life so much easier. JSTL wasn't around when cocoon set out to solve
these problems, I even sincerely believe that cocoon's influence
helped the development of techologies like jstl, so my point isn't
about which is better or worse.
Up until now I've been using jsps for the view controllers with
clearly named file..
/controller/fooController.jsp
jsp:useBean id=errors class=java.util.HashMap scope=request /
c:choose
c:when test=${empty param.email}
fmt:message key=message.email.required var=msg /
c:set target=${errors} property=email value=${msg}
/c:when
c:when test=${myvalidations:email(email)}
c:set target.. . etc
/c:when
..
c:choose
c:when test=${!empty errors}
jsp:forward page=mypage.jsp /
/c:when
..
in mypage.jsp iterate over error map or even a specialised java class
like ValidationError, and generate relevant xml.
Of course there's no reason why scripting or even continuations
couldn't be added, view controller logic in jstl wont be everyone's
cup to tea. But good ide and container support make it a reasonable
choice.
Again overly simple and maybe folk don't like jstl controllers, want
continuations etc, so its not like jstl can do everything. It would
need extending to do all that. But if folk want to talk about cost of
ownership, ide support, contractor/staff turnover and such like, while
maintaining SOC.
Lego is good, SOC is good, room to choose ajax or vanilla html output,
all these things are good. And before the standard kit supported it in
a usable manner was cocoon's main advantage. I see these advances in
jstl as some of the fruits of the cocoon project, and ironically not
leveraged by it. Refining jstl into something more aligned with cocoon
would seem to have more advantages than costs, would provide a clear
means of integrating legacy cocoon apps and maintain SOC.
Hope I haven't bored or annoyed anyone, just had a big itch for a long time.
Mark
On 12/11/05, Niclas Hedhman [EMAIL PROTECTED] wrote:
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
Re: [RF] Chainsaws and Seeds
Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... -- Stefano.
Re: [RF] Chainsaws and Seeds
Stefano Mazzocchi wrote: Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... IMHO, it does not matter whether the graphs are right or wrong, I think the web 2..0 movement has transcended the issue in any case. Model Based Architectures and Graphical interfaces have allowed far less technical people access to complex environments. I think, although I am not absolutely positive, that a java/pipeline/sitemap is a better base than perl/python upon which to build such systems. It is for that reason I posted the following 2 visions in another thread: As a first vision, I would like to see cocoon accessible to less technical people. This could be done with elegant simplicity and a graphical interface. Here is a good web 2.0 example http://www.activegrid.com/what/applicationbuilder.php. As a second vision, artifacts created by the graphical interface along with any written code could become the model from which alternative implementation systems might be generated. For example, a model POJO could be implementationally persisted in various ways. dave-
Re: [RF] Chainsaws and Seeds
dave- wrote: Stefano Mazzocchi wrote: Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... IMHO, it does not matter whether the graphs are right or wrong, I think the web 2..0 movement has transcended the issue in any case. Model Based Architectures and Graphical interfaces have allowed far less technical people access to complex environments. I think, although I am not absolutely positive, that a java/pipeline/sitemap is a better base than perl/python upon which to build such systems. It is for that reason I posted the following 2 visions in another thread: As a first vision, I would like to see cocoon accessible to less technical people. This could be done with elegant simplicity and a graphical interface. Here is a good web 2.0 example http://www.activegrid.com/what/applicationbuilder.php. As a second vision, artifacts created by the graphical interface along with any written code could become the model from which alternative implementation systems might be generated. For example, a model POJO could be implementationally persisted in various ways. dave- Should not be this more a Lepido[1] concern? Best Regards, Antonio Gallardo. [1] http://www.eclipse.org/lepido/
Re: [RF] Chainsaws and Seeds
On Friday 09 December 2005 02:21, Stefano Mazzocchi wrote: And in terms of moving the equi-cost point to the left, there are two fundmentally different variables to consider. for instance, if t y = a * b / x ` \/ total cost of ownership (y) ^ | o | o | | o | | o v | o \ 2. | o\ |o 1. +-- complexity (x) 1. Essential focus on lessening the threshold, i.e. lower a. 2. Increasing the power of the functionality that are required for really complex systems, i.e. increasing the root base. Often, these are also interlinked, and it is important that the lowering of a doesn't make ( b 1 )... I think everyone are at this point focusing on 1. The market talks about quick starters and Cocoon peeps wants to me too in that area. I don't give a flying fart about RubyOnRail as my gut says that it doesn't make it easier to become the next Rembrandt, only providing me with more cryons than the other kids. I think Stefano's RF is great. He challenges people's presence and motivations. If you want to do weblog apps - GO. If you want to DB record viewer app - GO. If you want JAWA (Just Another Web Application) - GO. GO - because there are 50 other frameworks out there, all of them with their strengths, weaknesses and hype. I am sure there is some that suits YOU, as well as me. JAWA is not why I keep my interest... The reason to stay, is not to compete with Struts, Tapestry, Wicket, RoR, PHP and every other JAWA framework out there. 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. 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. 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. 2. The most important aspect is the ability to generate media for different device models. No change required. 3. Americans have no clue about what is about to happen. Europeans are better prepared, and Cocoon is apparently a very European project. So, all of you who wants JAWA, Cocoon may not be the best tool. I don't think we should even try to become the best. Cocoon is already great in many aspects. We should concentrate on this, and become the defacto standard for mobile backends. Finally, my take on what Cocoon Really Needs. Cocoon needs a New Vision Statement. One paragraph of what Cocoon is all about, that blows my (the user's) mind away. Cocoon needs better Marketing. Struts didn't become Struts by developers complimenting each other on how great they were. Grab the opportunity of becoming the mobile backend 'standard'. Cocoon needs new Architecture. Marc's to the point list of how to get that organized is a good starting point. Cocoon needs better Documentation. Yeah, yeah, I know the story ;o) My 2 cents. Niclas
Re: [RF] Chainsaws and Seeds
Niclas Hedhman wrote: On Friday 09 December 2005 02:21, Stefano Mazzocchi wrote: And in terms of moving the equi-cost point to the left, there are two fundmentally different variables to consider. for instance, if t y = a * b / x ` \/ total cost of ownership (y) ^ | o |o | | o | |o v | o \ 2. | o\ |o 1. +-- complexity (x) 1. Essential focus on lessening the threshold, i.e. lower a. 2. Increasing the power of the functionality that are required for really complex systems, i.e. increasing the root base. Often, these are also interlinked, and it is important that the lowering of a doesn't make ( b 1 )... I think everyone are at this point focusing on 1. The market talks about quick starters and Cocoon peeps wants to me too in that area. I don't give a flying fart about RubyOnRail as my gut says that it doesn't make it easier to become the next Rembrandt, only providing me with more cryons than the other kids. Good one :-) I think Stefano's RF is great. Thanks. He challenges people's presence and motivations. If you want to do weblog apps - GO. If you want to DB record viewer app - GO. If you want JAWA (Just Another Web Application) - GO. GO - because there are 50 other frameworks out there, all of them with their strengths, weaknesses and hype. I am sure there is some that suits YOU, as well as me. JAWA is not why I keep my interest... The reason to stay, is not to compete with Struts, Tapestry, Wicket, RoR, PHP and every other JAWA framework out there. 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 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. 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. Cocoon will help moving stuff back to the server with very reasonable costs and move stuff from the server to the client gradually. *that* is, IMO, the real need: a web framework that is powerful and flexible, yet easy to use, that allows to position your web application on all possible shades between a controller that stays most on the client or most on the server, with the ability to fine-tune that over time with as much ease. 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. 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. 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, but as I said about, you might find that the complexity of multi-modality brings uniformity to the client (as it happens on the web) instead of bringing more complexity in the server side rendering engines, especially now that Mozilla Minimo and stuff like that are emerging and that mobiles (in order to run powerful games) will have more and more RAM and bigger screens. So, all of you who wants JAWA, Cocoon may not be the best tool. I don't think we should even try to become the best. Cocoon is already great in many aspects. We should concentrate on this, and become the defacto standard for mobile backends. I personally don't give a rat's ass
Re: [RF] Chainsaws and Seeds
On 08.12.2005, at 19:21, Stefano Mazzocchi wrote:Cocoon is what it is today, but what it is tomorrow is defined by what we, collectively, decide.Amen :)...I also started a long-winded response to this big thread(s) butsince at least a little crowd is going to meet soon at the ApacheConI ended up thinking a few high bandwidth f2f discussion and *then*get back the list might be a better time investment in the end. So let's make it short for now...A lot has been said ...and although there has been some disagreementto me it does not feel like the common vision is really so diverseat all. Simplicity and modularity! ...we just seem to have differentviews on *how* this should happen.I am also one of those who believe that Joel's article just doesn'tget it right. Just because you will *never* throw away all the code!And I assume when people are talking about "from scratch" we willstill find quite some code from the old codebase in the new one.I am sure we would get there through refactoring as well ...butthat's so much hard work ...and with such a big project it willmostly be just a constant pain ...ending in frustrated developersbut that's the last thing we need! We need back some more FUNdeveloping cocoon! (*sigh* The good old 2.x days spring to mind)How childish! Maybe ...but somehow I think that's how it works.Face it! We need the kick of the new! ...and since the core APIgot pretty much stable we added so much new stuff on top that thecore had no "air to breathe" anymore.Time seems to be right to put cocoon on a diet ...give the babysome air to breath and let's resurrect core development.I am sure we can do it again ...and this time we should haveenough people with old versions installed so we *have* to providea migration path. So no user should have to worry ;)Let's do it!...ups ...got longer than I wanted ;)cheers--Torsten PGP.sig Description: This is a digitally signed message part
Re: [RF] Chainsaws and Seeds
Stefano Mazzocchi wrote: snip/ What can we do? Two things: 1) breath and relax, we are not going to get run over: changing the slope does *NOT* change the nature of the function (they will understand that as soon as they cross that equi-cost point... and complexity grows even faster the more web 2.0-ish you become, because there are more and more variables that you don't control that get in the mix) I think it's an utopical vision: when the equi-point moves to the right, people realize that they're reaching the limit of their framwork once: - it's too late to envision changing for another one, - they reached a very intimate knowledge of their framework, precisely because that point is more far to the right. What this means is that chances that they switch to another platform that can handle high complexity but has a steep learning curve are very low. Also, we have to consider that it's not only the slope of the other technologies that has flattened, but also the slope of Cocoon that has become steeper. So the equi-point has moved far right because of the combination of these two factors, and getting into Cocoon when you tried a framework with an easier initial approach will seem like a impossible or not-worth-it task. snip/ But the ASF contains the rules for revolutionaries. This states that every committer is allowed to propose an 'internal fork' but there a few things that it's not supposed to do, the most important being, use the name of the same project. So, if Sylvain wants to start an internal fork, he can and nobody can stop him, but he has to pick a codename that has nothing to do with cocoon and cannot release it to the public (as distribution) before the cocoon PMC allows that to happen. Ok. Actually, I was surprised by so many people answering positively to my RT, and what started as a rant and potential solutions turned into a march towards a revolution, in an uncontrolled way. Now I understand this isn't the way to go to ensure a smooth cohabitation between this experiment and the work that has to be done on Cocoon. So I will not name it Cocoon-NG, XP or whatever. Searching for a name, I saw my cat walk by, and decided to pick up his name for this experiment. So that will be Kiwi, which obviously makes no reference to Cocoon. Let's also calm down all these vision talks (which seem to have happened already) and work more quielty on some proof of concept with this pull-based pipeline API, and see what comes out. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RF] Chainsaws and Seeds
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.
