Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans wrote: > Ross Gardler wrote: > > > > -1 over at Forrest one of our devs is experimenting with the Ajax block. > > We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax > > into the CForms block would prevent us from using it since we don't want > > to bundle CForms for fear of confusing the boundaries between Forrest > > (an XML publishing engine) and Cocoon (a web application framework). Definitely keep Ajax block separate. However i don't agree with your suggestion about never using CForms with Forrest. The mission is broad. -David > ok cool so the ajax block can be reused from other frameworks/blocks as > well. Let's keep them separated then ! > > Thanks > Jorg
Re: [RT] Ditching the environment abstraction
On Wednesday 14 December 2005 09:31, Sylvain Wallez wrote: > > Both make very much sense. > > > > Which means cleaning up the mess everywhere ;-);-) Granted. I just wanted to say that "for me, improvemets in either is good". But that the discussion left out "who is most important now", and if that is established, it becomes fairly obvious of what to do next, and avoiding the ping-ponging of whether this or that implementation detail will make Cocoon cleaner. Cheers Niclas
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Ross Gardler wrote: > > -1 over at Forrest one of our devs is experimenting with the Ajax block. > We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax > into the CForms block would prevent us from using it since we don't want > to bundle CForms for fear of confusing the boundaries between Forrest > (an XML publishing engine) and Cocoon (a web application framework). ok cool so the ajax block can be reused from other frameworks/blocks as well. Let's keep them separated then ! Thanks Jorg
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans wrote: Antonio Gallardo wrote: Also, please don't forget the ajax block. It is needed by forms. ;-) Is ajax really a block on it's own ? I mean i know it can be plugged into cforms to make forms ajax aware, but is it useable by other blocks as well ? I'm not really uptodate with this stuff, just curious whether it would make sense to move the ajax code to the cforms block. Or do we prefer to have separate release cycles for these two? -1 over at Forrest one of our devs is experimenting with the Ajax block. We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax into the CForms block would prevent us from using it since we don't want to bundle CForms for fear of confusing the boundaries between Forrest (an XML publishing engine) and Cocoon (a web application framework). Ross
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Antonio Gallardo wrote: > Also, please don't forget the ajax block. It is needed by forms. ;-) > Is ajax really a block on it's own ? I mean i know it can be plugged into cforms to make forms ajax aware, but is it useable by other blocks as well ? I'm not really uptodate with this stuff, just curious whether it would make sense to move the ajax code to the cforms block. Or do we prefer to have separate release cycles for these two? Jorg
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Vadim Gritsenko wrote: Niclas Hedhman wrote: On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote: For the versioning, we could for example release a 2.2 soon, change the environment abstract after that and then release a 2.3 later this year. Two more releases this year, YEAH!!! That's a remarkable spirit ;o) Just kidding... I think Carsten is right, stablize and release 2.2 ASAP. There is no +1 large enough to convey how much I agree. Considering we had/have issues with switching the build system, adding the Environment removal will only push the release out further. I'd propose solidify 2.2 as is and push it out. You want to get rid of Environment, make that a focus of 2.3.
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Upayavira wrote: I would also ask whether we should consider replacing the serializers in core with those in the serializer block. Why would you replace single class which works in 99% of cases with 4Mb of code? Vadim
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Niclas Hedhman wrote: On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote: For the versioning, we could for example release a 2.2 soon, change the environment abstract after that and then release a 2.3 later this year. Two more releases this year, YEAH!!! That's a remarkable spirit ;o) Just kidding... I think Carsten is right, stablize and release 2.2 ASAP. There is no +1 large enough to convey how much I agree. Vadim
Re: [RT] Ditching the environment abstraction
Sylvain Wallez wrote: So my opinion about ditching our abstraction is that, as we say in France, it is urgent to wait. Along with the backwards compatibility problems that ditching the abstraction in 2.2 may lead to, we should see if that common abstraction comes to life and then consider using it. I'd very much support an effort to improve/cleanup environment abstraction (as was started with getParameters), and even more so if this abstraction is commonly shared. Removing abstraction simply means substituting our abstraction with Servlet abstraction which does not look that attractive at all. Especially if jakarta-commons & struts end up having much better, user friendly abstraction. Vadim
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Niclas Hedhman schrieb: > On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote: > >>For the versioning, we could for example release a 2.2 soon, change the >>environment abstract after that and then release a 2.3 later this year. > > > Two more releases this year, YEAH!!! > That's a remarkable spirit ;o) > > Just kidding... > > I think Carsten is right, stablize and release 2.2 ASAP. > Thanks :) Now, I haven't seen any other thing apart from the build system that people really think that has to be fixed for 2.2 - so if we concentrate on m2 now, we should be able to release in january. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Ditching the environment abstraction
Niclas Hedhman wrote: On Wednesday 14 December 2005 04:12, Carsten Ziegeler wrote: From a users perspective (= the average Cocoon developer), most of the "messiness" is hidden. She does not have to deal with how the tree processor works, or with implementing an own pipeline etc. All these interfaces and components should be well hidden to her. Apparently, you guys need to discuss "who" you are targetting, before agreeing on what to do about it; Daniel - talking Cocoon internals developer, hoping to extend the number of active participants in Cocoon core development. Carsten - talking about making things better for developers of Cocoon components. Both make very much sense. Which means cleaning up the mess everywhere ;-) Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Upayavira wrote: Jorg Heymans wrote: Also: are we carrying forward all blocks to 2.2 or is this the time where we ditch the obscure, rarely used and "blocks that don't really deserve to be a block" blocks? I'ld say we choose the 10 most often used and well known blocks and let the users voice their concern about those blocks we aren't taking forward. If enough noise, we can then still decide to support these blocks ourselves again or even offer it to dedicated users to maintain themselves. IMO we should be aiming to have either two or three releases: bare, small or complete. I would prefer not to have the complete release, because I would like us to have _a lot_ more blocks, as blocks _do_ make sense, they just don't make sense as the core. So if we start making "complete" releases, that complete release could start to grow into something unmanagable. So, we identify 'core' blocks, if we haven't already. Those get included in the 'small' build, the rest can be downloaded either via Maven or as separate zips. My take on core blocks is: * template * forms * javaflow Why javaflow? Also, please don't forget the ajax block. It is needed by forms. ;-) I would also ask whether we should consider replacing the serializers in core with those in the serializer block. +1 Best Regards, Antonio Gallardo.
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Daniel Fagerstrom wrote: Upayavira skrev: I would also ask whether we should consider replacing the serializers in core with those in the serializer block. Better move the current core serializers to an own block. IMO we should have a core that only contains the minimal infrastructure and core apis needed for Cocoon, everything els, including sitemap components should go into blocks. Yes. can we move the current core serializer to a "deprecated" block? Best Regards, Antonio Gallardo. /Daniel
Re: [RT] Ditching the environment abstraction
On Wednesday 14 December 2005 04:12, Carsten Ziegeler wrote: > From a > users perspective (= the average Cocoon developer), most of the > "messiness" is hidden. She does not have to deal with how the tree > processor works, or with implementing an own pipeline etc. All these > interfaces and components should be well hidden to her. Apparently, you guys need to discuss "who" you are targetting, before agreeing on what to do about it; Daniel - talking Cocoon internals developer, hoping to extend the number of active participants in Cocoon core development. Carsten - talking about making things better for developers of Cocoon components. Both make very much sense. Cheers Niclas
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote: > For the versioning, we could for example release a 2.2 soon, change the > environment abstract after that and then release a 2.3 later this year. Two more releases this year, YEAH!!! That's a remarkable spirit ;o) Just kidding... I think Carsten is right, stablize and release 2.2 ASAP. Cheers Niclas
Re: [RT] Ditching the environment abstraction
Ralph Goers wrote: Sylvain Wallez wrote: Which makes actually two different abstractions for the same purpose, and makes blocking the outputstream on our own abstraction useless, as people can access it anyway. It would be better IMO to have a single abstraction, but _control_ how the outputstream is used, e.g. by allowing it to be fetched only once. My understanding (maybe incorrectly) is that pipelines can start writing to the output stream and if an error occurs that stream can be abandoned in favor of a new one containing the error response. How would you propose that that be handled - acknowledging that you don't think that they should be in 2.2? That's right, but only to the extent of what's buffered by the servlet engine. This is implemented Environment.tryResetResponse(). So allowing it to be fetched only once may not be the right strategy, but the fact is that the output stream _must_ be available and that we _can_ control its use. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] Ditching the environment abstraction
Ralph Goers wrote: Sylvain Wallez wrote: Which makes actually two different abstractions for the same purpose, and makes blocking the outputstream on our own abstraction useless, as people can access it anyway. It would be better IMO to have a single abstraction, but _control_ how the outputstream is used, e.g. by allowing it to be fetched only once. My understanding (maybe incorrectly) is that pipelines can start writing to the output stream and if an error occurs that stream can be abandoned in favor of a new one containing the error response. How would you propose that that be handled - acknowledging that you don't think that they should be in 2.2? That's right, but only to the extent of what's buffered by the servlet engine. This is implemented Environment.tryResetResponse(). So allowing it to be fetched only once may not be the right strategy, but the fact is that the output stream _must_ be available and that we _can_ control its use. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] Ditching the environment abstraction
Sylvain Wallez wrote: Which makes actually two different abstractions for the same purpose, and makes blocking the outputstream on our own abstraction useless, as people can access it anyway. It would be better IMO to have a single abstraction, but _control_ how the outputstream is used, e.g. by allowing it to be fetched only once. My understanding (maybe incorrectly) is that pipelines can start writing to the output stream and if an error occurs that stream can be abandoned in favor of a new one containing the error response. How would you propose that that be handled - acknowledging that you don't think that they should be in 2.2? Ralph
Re: [RT] Ditching the environment abstraction
On 13.12.2005 22:20, Carsten Ziegeler wrote: I have the feeling that changing this does not buy us something and that does it not make life easier - I might be wrong though. Now, I still think we should make the request/response objects more easily accessible somehow. +1 to both. Jörg
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler wrote: Ralph Goers wrote: Daniel Fagerstrom wrote: The servlet set of apis is allready an abstraction, we have due to historical circumstances another abstraction of the same concepts. To me the abstractions look fairly similar, except for the Cocoon aditions that have been mentioned. What am I missing more specifically? What exactly are the sevlet apis an abstraction of? We could have compablity wrapper. Question is do we want to simplify or not? What, exactly are we simplifying? There is no way that we won't always have a "real" HttpServletRequest. AFAICS there is no way that we can just use it. So what would replace the existing Request object? In order to understand this I really need to know exactly what the new object would be. Hmm, now, one possible way of simplifying could be to extend the HttpServletRequest/Response objects, so if you need an HttpServletRequest somewhere you directly have it. But for example our Response object does not provide access to the outputstream, and I'm sure even if we extend the HttpServletResponse interface, we want to block direct access to the output stream (by throwing an exception). We _need_ direct access to the output stream. Ajax applications require to move away from the request/page-response paradigm that prevailed up to now. The controller must be able to send a direct response to the client for empty control responses or raw data. CForms required this for to handle the end of the form interaction in Ajax mode, and I directly accessed the HttpServletRequest for this, how heretic it might seem :-) And there might be other examples for this - so in the end if you need a real servlet response object you can't use our response object as we block some operations. Currently, we store the original http servlet request/response objects in the object map next to our own versions of it. So if you really need the original objects, you can look them up. Which makes actually two different abstractions for the same purpose, and makes blocking the outputstream on our own abstraction useless, as people can access it anyway. It would be better IMO to have a single abstraction, but _control_ how the outputstream is used, e.g. by allowing it to be fetched only once. I have the feeling that changing this does not buy us something and that does it not make life easier - I might be wrong though. Now, I still think we should make the request/response objects more easily accessible somehow. Yup. Now changing these abstractions aren't for Cocoon 2.2 IMO. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] Ditching the environment abstraction
Ralph Goers wrote: > > Daniel Fagerstrom wrote: > > >>The servlet set of apis is allready an abstraction, we have due to >>historical circumstances another abstraction of the same concepts. To >>me the abstractions look fairly similar, except for the Cocoon >>aditions that have been mentioned. What am I missing more specifically? > > > What exactly are the sevlet apis an abstraction of? > > >>We could have compablity wrapper. Question is do we want to simplify >>or not? > > > What, exactly are we simplifying? There is no way that we won't always > have a "real" HttpServletRequest. AFAICS there is no way that we can > just use it. So what would replace the existing Request object? In > order to understand this I really need to know exactly what the new > object would be. > Hmm, now, one possible way of simplifying could be to extend the HttpServletRequest/Response objects, so if you need an HttpServletRequest somewhere you directly have it. But for example our Response object does not provide access to the outputstream, and I'm sure even if we extend the HttpServletResponse interface, we want to block direct access to the output stream (by throwing an exception). And there might be other examples for this - so in the end if you need a real servlet response object you can't use our response object as we block some operations. Currently, we store the original http servlet request/response objects in the object map next to our own versions of it. So if you really need the original objects, you can look them up. I have the feeling that changing this does not buy us something and that does it not make life easier - I might be wrong though. Now, I still think we should make the request/response objects more easily accessible somehow. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Ditching the environment abstraction
Daniel Fagerstrom wrote: The servlet set of apis is allready an abstraction, we have due to historical circumstances another abstraction of the same concepts. To me the abstractions look fairly similar, except for the Cocoon aditions that have been mentioned. What am I missing more specifically? What exactly are the sevlet apis an abstraction of? We could have compablity wrapper. Question is do we want to simplify or not? What, exactly are we simplifying? There is no way that we won't always have a "real" HttpServletRequest. AFAICS there is no way that we can just use it. So what would replace the existing Request object? In order to understand this I really need to know exactly what the new object would be. Ralph
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Look, Cocoons current messiness depends on a large amount of small things. If we not are able to improve these areas one at a time Cocoon will stay as messy as it is. Sure, but I really think messiness is a very hard work here. I know, but I'm volonter to do part of it, and think it is possible and desirable to make Cocoon less monolithic. From a users perspective (= the average Cocoon developer), most of the "messiness" is hidden. She does not have to deal with how the tree processor works, or with implementing an own pipeline etc. All these interfaces and components should be well hidden to her. I have heard quite a few users wanting Cocoon to be reusable in parts. But beside that this is mainly a developer question. We are a handfull people who dare to touch the core at all and most of us think it is a pain to develop thing due to monolithic design and hard to understand dependencies. This means that a large part of the developer community feel a much to high threshold to join in improving Cocoon. Also it takes a lot of fun away from us. ... But I'm not sure, if this incremental approach is working here. If we block trying it, we will never know. /Daniel
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Reinhard Poetz skrev: --- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb: Daniel Fagerstrom wrote: More seriously, it was an RT, I wanted to hear what people think and if there was any problems that I hadn't thought about. I will of course cast a vote before commiting anything. We could possibly provide some optional back compability mode that puts the environment abstraction objects in the object model. But I would suppose most users would be happy to get rid of this extra complication. Don't get me wrong, I'm not absolutely against ditching the abstraction (see my last mail in the thread), but I think from the response so far, there is no big cheering group out there dancing around singing "yes, that's exactly what we wanted for years". So I think, unless there are really some more users saying, "yes, please, do that" we should simply not do it. For the versioning, we could for example release a 2.2 soon, change the environment abstract after that and then release a 2.3 later this year. If I understand Daniel correctly, he wants to change it because this simplifies his work on the block implementation. Right? Simplification isn't the main issue for the blocks, even if that is achieved as well. The main reason is to simplify controller development and integrating Cocoon applications with external applications through the block system. /Daniel
Re: [RT] Ditching the environment abstraction
Sylvain Wallez skrev: Daniel Fagerstrom wrote: It seem like we all agree about that the Cocoon core need to be simplified, although we have different opinions about how to achieve it. IMO it can be done in steps by refactoring of the trunk. One of the complications with Cocoon is the environment abstraction: o.a.c.environment.Request, Response, Context etc. They are similar but not identical to the javax.servlet and javax.servlet.http interfaces, which means yet another thing to learn for the user. It also means that it becomes more complicated to use externally developed components, as these typically implement the servlet family of interfaces. Furthermore it leads to a more complicated setup process of Cocoon. So, do we need this extra layer of abstraction? Yesterday evening, we had a discussion with some Struts people, and interestingly enough, they wanted to know more about how we abstracted the environment to define an abstraction layer in jakarta commons so that people can develop their webapp modules and deploy them transparently as portlets or servlets by using the proper implementation of the abstraction. The servlet set of apis is allready an abstraction, we have due to historical circumstances another abstraction of the same concepts. To me the abstractions look fairly similar, except for the Cocoon aditions that have been mentioned. What am I missing more specifically? So what is it that the struts people are looking for that needs a new abstraction? So my opinion about ditching our abstraction is that, as we say in France, it is urgent to wait. Along with the backwards compatibility problems that ditching the abstraction in 2.2 may lead to, We could have compablity wrapper. Question is do we want to simplify or not? we should see if that common abstraction comes to life and then consider using it. Ok, I start consider joining the rewrite from scracth camp ;) /Daniel
Re: [RT] Ditching the environment abstraction
Daniel Fagerstrom wrote: > Look, Cocoons current messiness depends on a large amount of small > things. If we not are able to improve these areas one at a time Cocoon > will stay as messy as it is. > Sure, but I really think messiness is a very hard work here. From a users perspective (= the average Cocoon developer), most of the "messiness" is hidden. She does not have to deal with how the tree processor works, or with implementing an own pipeline etc. All these interfaces and components should be well hidden to her. So, in these situations, the developer deals with either writing sitemap components - and then there is the problem I mentioned, that it'S not obvious *how* to get hold of the request object. I consider *this* the messiness, but not the request object itself. Or the developer writes some business logic/flow using own components/flow. So, imho there are two levels of "messiness" :) Anyways, in the end it might not play a role - I don't know. Look, in the end, I'm absolutely in favor of changing parts of Cocoon and make them simpler and easier to use. But I'm not sure, if this incremental approach is working here. Which in the end brings us back to the discussion "starting from scratch vs. incremental changes". Ok, I guess noone wants to get into this atm. I think, just write an exact proposal, how you want to change the abstraction and we can then discuss this and vote on that later on. But I would really suggest that we get much more responses/opinions before doing this changes. Especially I would like to hear some user opinions as they are effected by such changes. > So now we have the situation that we all agree about that there is need > for a radical improvement of Cocoon in general. But it seem rather hard > get any decisions about changing anything in particular. > Yepp, exactly - there is always someone disagreeing :) In we are in this state for a very long time now. Don't know how to change this though. > Maybe Cocoon of today is what we deserve ;) > Definitly. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler skrev: Leszek Gawron schrieb: Carsten Ziegeler wrote: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? Moreover we have just introduced Session.getAttributes, Request.getParamters and so on. There are no equivalents in pure HTTP interfaces. Yepp, I actually thought about this last night and I think now, we should not ditch this abstraction. If we would ditch it, we have to cope with two problems: compatibility (noone wants to rewrite all of the code) and additional functions (which are used throughout Cocoon). Now, we could solve both problems by extending the servlet apis, but then we still use our own interfaces in the end and nothing changes. In the recent discussions many people want to see controllers as first class citicens in Cocoon, so that we can use flowscript or javaflow as the main controller, that calls the sitemap controller in turn. Also we need room to start experimenting with new controllers, as the "convention" controller that Berin started to work on. The blocks architecture allready contains two new controllers: a block dispatch controller that is the main controller and take care of mounted blocks and delegate the controll to a block controller that represents a particular block. The block controller in turn calls a sitemap controller. Now I would like to generalise this so that the block controller can be configured to dispatch to any controller not just be hard wired to the sitemap controller. Also I would like to make the various controllers as independent of each other as possible to break down the current monolithic state of Cocoon core that makes it such a pain to develop in. Now for these new developments we should IMO not depend on the unnecessary complication that our environment abstraction means. At least I would like to use the servlet apis on the controller level. We could introduce the own environment abstarction first inside the sitemap controller. I did several Cocoon development training courses in the last years and I think our own abstraction by itself was never the problem. The big problem most times is, that people do not know/see that we actually have a request object and how they can obtain it in there own code. If you compare our pipeline component interfaces with interfaces from other web frameworks there is an obvious difference: other frameworks/specs (servlets, portlets etc.) always have a request and response object directly in the signature of a method. So it's directly visible. Our components have a map called object model and everything is hidden in this map. So, I think changing this would be much more helpful for newbies. They directly see a request/response object somewhere and than it's obvious how to use them no matter what the package of that object is. Look, Cocoons current messiness depends on a large amount of small things. If we not are able to improve these areas one at a time Cocoon will stay as messy as it is. So now we have the situation that we all agree about that there is need for a radical improvement of Cocoon in general. But it seem rather hard get any decisions about changing anything in particular. Maybe Cocoon of today is what we deserve ;) Now, basically another problem we have which is somehow related to this is that our components get pooled. I think if we would switch to a factory based approach for sitemap components (like we discussed and already started), we could change the interface for those factories and directly path the request/response object into them. I have the hope that this will decrease the learning curve in this area. Ok. Any link to the discussion? /Daniel
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Upayavira skrev: Jorg Heymans wrote: Also: are we carrying forward all blocks to 2.2 or is this the time where we ditch the obscure, rarely used and "blocks that don't really deserve to be a block" blocks? I'ld say we choose the 10 most often used and well known blocks and let the users voice their concern about those blocks we aren't taking forward. If enough noise, we can then still decide to support these blocks ourselves again or even offer it to dedicated users to maintain themselves. IMO we should be aiming to have either two or three releases: bare, small or complete. I would prefer not to have the complete release, because I would like us to have _a lot_ more blocks, as blocks _do_ make sense, they just don't make sense as the core. So if we start making "complete" releases, that complete release could start to grow into something unmanagable. So, we identify 'core' blocks, if we haven't already. Those get included in the 'small' build, the rest can be downloaded either via Maven or as separate zips. My take on core blocks is: * template * forms * javaflow +1 I would also ask whether we should consider replacing the serializers in core with those in the serializer block. Better move the current core serializers to an own block. IMO we should have a core that only contains the minimal infrastructure and core apis needed for Cocoon, everything els, including sitemap components should go into blocks. /Daniel
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans skrev: Carsten Ziegeler wrote: I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. I've been working a bit more behind the scenes lately to get excalibur to behave properly under m2. I am currently switching the flat layout in the whiteboard to the new excalibur poms to see how they behave and do first tests. Once i'm done there i can focus more on the deployment integration again. Great! What about the repository reorganisation I suggested in [1]? Given a more flat and m2 consistent layout, i can *easily* put it under continuum control like i did with excalibur [2]. Note that we wouldn't use continuum's CI features as such, but merely use it as an automated snapshot release tool. It would thus replace my cronned shell script for doing snapshot releases and make it possible to force a snapshot release at the click of a button. +1 The only thing about the repo reorg is that i don't want to stall current development momentum, but frankly i don't really see a way not to - at least for a few days. Wait until after ApacheCon and go ahead after that. Also: are we carrying forward all blocks to 2.2 or is this the time where we ditch the obscure, rarely used and "blocks that don't really deserve to be a block" blocks? I'ld say we choose the 10 most often used and well known blocks and let the users voice their concern about those blocks we aren't taking forward. If enough noise, we can then still decide to support these blocks ourselves again or even offer it to dedicated users to maintain themselves. +1 With 2.2 we have separate release cycles for the different blocks. So if no one is interested enough to do a release of a block it will not be released. /Daniel
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Torsten Curdt wrote: While I agree that it is OK to break compatibility to some degree between 2.1 and 2.2, I think this is more of a change than I'd really like to see between 2.1 and 2.2 as it will require modifications to every Cocoon application. Either we allow such required modifications or we need to start the 3.0 thingy. That's exactly what all the fuzz is about - loosening contracts. Further keeping all the contracts is what kills. People ...let go a bit! Sorry, I guess I need to be clearer. I don't believe you can realistically "dump" the Request abstraction. I believe any attempt to do that wouldn't work. This is because Cocoon cannot directly use the "real" request object as we have extra methods and we cannot let the application directly write to the "real" output buffer. What this means is that the existing Cocoon Request object will end up just implementing javax.servlet.http.HttpServletRequest. This is not necessarily a bad thing as the Cocoon Request object could then be passed to many functions that request an HttpServletRequest. However, there will probably still be cases where the container's HttpServletRequest will still need to be obtained.
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
--- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb: > Daniel Fagerstrom wrote: > > > > More seriously, it was an RT, I wanted to hear > what people think and if > > there was any problems that I hadn't thought > about. I will of course > > cast a vote before commiting anything. We could > possibly provide some > > optional back compability mode that puts the > environment abstraction > > objects in the object model. > > > > But I would suppose most users would be happy to > get rid of this extra > > complication. > > > Don't get me wrong, I'm not absolutely against > ditching the abstraction > (see my last mail in the thread), but I think from > the response so far, > there is no big cheering group out there dancing > around singing "yes, > that's exactly what we wanted for years". So I > think, unless there are > really some more users saying, "yes, please, do > that" we should simply > not do it. > For the versioning, we could for example release a > 2.2 soon, change the > environment abstract after that and then release a > 2.3 later this year. If I understand Daniel correctly, he wants to change it because this simplifies his work on the block implementation. Right? -- Reinhard ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] Ditching the environment abstraction
Daniel Fagerstrom wrote: It seem like we all agree about that the Cocoon core need to be simplified, although we have different opinions about how to achieve it. IMO it can be done in steps by refactoring of the trunk. One of the complications with Cocoon is the environment abstraction: o.a.c.environment.Request, Response, Context etc. They are similar but not identical to the javax.servlet and javax.servlet.http interfaces, which means yet another thing to learn for the user. It also means that it becomes more complicated to use externally developed components, as these typically implement the servlet family of interfaces. Furthermore it leads to a more complicated setup process of Cocoon. So, do we need this extra layer of abstraction? Yesterday evening, we had a discussion with some Struts people, and interestingly enough, they wanted to know more about how we abstracted the environment to define an abstraction layer in jakarta commons so that people can develop their webapp modules and deploy them transparently as portlets or servlets by using the proper implementation of the abstraction. So my opinion about ditching our abstraction is that, as we say in France, it is urgent to wait. Along with the backwards compatibility problems that ditching the abstraction in 2.2 may lead to, we should see if that common abstraction comes to life and then consider using it. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Daniel Fagerstrom wrote: > > More seriously, it was an RT, I wanted to hear what people think and if > there was any problems that I hadn't thought about. I will of course > cast a vote before commiting anything. We could possibly provide some > optional back compability mode that puts the environment abstraction > objects in the object model. > > But I would suppose most users would be happy to get rid of this extra > complication. > Don't get me wrong, I'm not absolutely against ditching the abstraction (see my last mail in the thread), but I think from the response so far, there is no big cheering group out there dancing around singing "yes, that's exactly what we wanted for years". So I think, unless there are really some more users saying, "yes, please, do that" we should simply not do it. For the versioning, we could for example release a 2.2 soon, change the environment abstract after that and then release a 2.3 later this year. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Ditching the environment abstraction
Leszek Gawron schrieb: > Carsten Ziegeler wrote: > >>In general I agree with this - it makes learning Cocoon internal a >>little bit easier. But I think the current environment api is not our >>biggest problem. Anyways, our current Request object has more >>functionality as the servlet request object, e.g. to get the sitemap >>prefix and sitemap uri and more important the request attribute handling >>for internal requests. How can we keep this functionality when switching >>to the servlet api? > > Moreover we have just introduced Session.getAttributes, > Request.getParamters and so on. There are no equivalents in pure HTTP > interfaces. > > Yepp, I actually thought about this last night and I think now, we should not ditch this abstraction. If we would ditch it, we have to cope with two problems: compatibility (noone wants to rewrite all of the code) and additional functions (which are used throughout Cocoon). Now, we could solve both problems by extending the servlet apis, but then we still use our own interfaces in the end and nothing changes. I did several Cocoon development training courses in the last years and I think our own abstraction by itself was never the problem. The big problem most times is, that people do not know/see that we actually have a request object and how they can obtain it in there own code. If you compare our pipeline component interfaces with interfaces from other web frameworks there is an obvious difference: other frameworks/specs (servlets, portlets etc.) always have a request and response object directly in the signature of a method. So it's directly visible. Our components have a map called object model and everything is hidden in this map. So, I think changing this would be much more helpful for newbies. They directly see a request/response object somewhere and than it's obvious how to use them no matter what the package of that object is. Now, basically another problem we have which is somehow related to this is that our components get pooled. I think if we would switch to a factory based approach for sitemap components (like we discussed and already started), we could change the interface for those factories and directly path the request/response object into them. I have the hope that this will decrease the learning curve in this area. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Upayavira wrote: > For me, the absolute most important thing is getting the build working > again with the excalibur stuff. I'm here at ApacheCon with Maven chaps > around, and the easier it is for me to 'grok' the current Maven setup, > the more likely I am to be able to understand and explore with them > where we should go next. i'll see about getting this fixed. I've fixed the ones in the whiteboard but am unable to commit ATM. Jorg
Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans wrote: > Also: are we carrying forward all blocks to 2.2 or is this the time > where we ditch the obscure, rarely used and "blocks that don't really > deserve to be a block" blocks? I'ld say we choose the 10 most often used > and well known blocks and let the users voice their concern about those > blocks we aren't taking forward. If enough noise, we can then still > decide to support these blocks ourselves again or even offer it to > dedicated users to maintain themselves. IMO we should be aiming to have either two or three releases: bare, small or complete. I would prefer not to have the complete release, because I would like us to have _a lot_ more blocks, as blocks _do_ make sense, they just don't make sense as the core. So if we start making "complete" releases, that complete release could start to grow into something unmanagable. So, we identify 'core' blocks, if we haven't already. Those get included in the 'small' build, the rest can be downloaded either via Maven or as separate zips. My take on core blocks is: * template * forms * javaflow I would also ask whether we should consider replacing the serializers in core with those in the serializer block. Regards, Upayavira
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
While I agree that it is OK to break compatibility to some degree between 2.1 and 2.2, I think this is more of a change than I'd really like to see between 2.1 and 2.2 as it will require modifications to every Cocoon application. Either we allow such required modifications or we need to start the 3.0 thingy. That's exactly what all the fuzz is about - loosening contracts. Further keeping all the contracts is what kills. People ...let go a bit! cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans wrote: > > > Carsten Ziegeler wrote: > >> >> I strongly suggest that we start creating roadmaps. This also would make >> the development of Cocoon for users much more transparent. Currently I >> have only two points which I really think have to be finished for 2.2: >> the build/deployment stuff and making the current blocks available >> separatly/providing an own versioning for them. So as soon as the m2 >> integration works, we can polish 2.2 a little bit and then release the >> core and each blocks as 2.2 and from the on develop the core and the >> blocks independently and release them independently. Everything else can >> follow later on. >> > > > I've been working a bit more behind the scenes lately to get excalibur > to behave properly under m2. I am currently switching the flat layout in > the whiteboard to the new excalibur poms to see how they behave and do > first tests. Once i'm done there i can focus more on the deployment > integration again. > > What about the repository reorganisation I suggested in [1]? Given a > more flat and m2 consistent layout, i can *easily* put it under > continuum control like i did with excalibur [2]. Note that we wouldn't > use continuum's CI features as such, but merely use it as an automated > snapshot release tool. It would thus replace my cronned shell script for > doing snapshot releases and make it possible to force a snapshot release > at the click of a button. > > The only thing about the repo reorg is that i don't want to stall > current development momentum, but frankly i don't really see a way not > to - at least for a few days. For me, the absolute most important thing is getting the build working again with the excalibur stuff. I'm here at ApacheCon with Maven chaps around, and the easier it is for me to 'grok' the current Maven setup, the more likely I am to be able to understand and explore with them where we should go next. > Also: are we carrying forward all blocks to 2.2 or is this the time > where we ditch the obscure, rarely used and "blocks that don't really > deserve to be a block" blocks? I'ld say we choose the 10 most often used > and well known blocks and let the users voice their concern about those > blocks we aren't taking forward. If enough noise, we can then still > decide to support these blocks ourselves again or even offer it to > dedicated users to maintain themselves. See separate mail. Upayavira
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler wrote: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? Moreover we have just introduced Session.getAttributes, Request.getParamters and so on. There are no equivalents in pure HTTP interfaces. And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Carsten Ziegeler wrote: I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. I've been working a bit more behind the scenes lately to get excalibur to behave properly under m2. I am currently switching the flat layout in the whiteboard to the new excalibur poms to see how they behave and do first tests. Once i'm done there i can focus more on the deployment integration again. What about the repository reorganisation I suggested in [1]? Given a more flat and m2 consistent layout, i can *easily* put it under continuum control like i did with excalibur [2]. Note that we wouldn't use continuum's CI features as such, but merely use it as an automated snapshot release tool. It would thus replace my cronned shell script for doing snapshot releases and make it possible to force a snapshot release at the click of a button. The only thing about the repo reorg is that i don't want to stall current development momentum, but frankly i don't really see a way not to - at least for a few days. Also: are we carrying forward all blocks to 2.2 or is this the time where we ditch the obscure, rarely used and "blocks that don't really deserve to be a block" blocks? I'ld say we choose the 10 most often used and well known blocks and let the users voice their concern about those blocks we aren't taking forward. If enough noise, we can then still decide to support these blocks ourselves again or even offer it to dedicated users to maintain themselves. Regards, Jorg [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/57694 [2] http://cocoon.zones.apache.org:7532/continuum/servlet/continuum
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Carsten Ziegeler apache.org> writes: > >>And for me the most important question :) What is the suggested > >>timeframe/version for this? Do you want to do this for 2.2? > > > > So it sounds like 2.2. > > Hmm, ok, this is a point where I disagree :) I think we should get 2.2 > out asap to have our mind clear for new stuff. +1 > So as soon as the m2 > integration works, we can polish 2.2 a little bit and then release the > core and each blocks as 2.2 and from the on develop the core and the > blocks independently and release them independently. Everything else can > follow later on. +1 Let's get 2.2 "as is" and start with "ditching the environment" immediately after the first 2.2 release, so it will go in a 2.3 or however it will be named. Jörg
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Gianugo Rabellino wrote: I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, While I agree that it is OK to break compatibility to some degree between 2.1 and 2.2, I think this is more of a change than I'd really like to see between 2.1 and 2.2 as it will require modifications to every Cocoon application. In addition, I'm still not clear as to where the extra request methods would go. Ralph
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Berin Loritsch skrev: Gianugo Rabellino wrote: On 12/13/05, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the "specification", but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, Just make sure it doesn't break anyone accidentally. No risk, we will break peoples code intentionally ;) More seriously, it was an RT, I wanted to hear what people think and if there was any problems that I hadn't thought about. I will of course cast a vote before commiting anything. We could possibly provide some optional back compability mode that puts the environment abstraction objects in the object model. But I would suppose most users would be happy to get rid of this extra complication. /Daniel
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Gianugo Rabellino skrev: On 12/13/05, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the "specification", but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Agree. We probably have a couple of milestone releases first. If we ditch it during the milestone phase it should be ok. But definitly not between revisions. The only layer in Cocoon where users has any contact with the environment abstraction is through the object model in sitemap components. So we can "push" the use of the environment abstraction down a couple of layers in the Cocoon internal without affecting anybody. But of course I would prefer geting rid of them once and for all. /Daniel
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Gianugo Rabellino wrote: On 12/13/05, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the "specification", but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, Just make sure it doesn't break anyone accidentally.
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
On 12/13/05, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > I agree that the main focus must be to get a 2.2 release. So the > question is what to do with the real blocks. They are currently rather > close to the "specification", but we don't know if the specification is > good enough without getting experience from the blocks. > > For ditching the environment abstraction, that should of course not > block any releases. It can always be solved by making the change in a > branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the "specification", but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. /Daniel Carsten Ziegeler skrev: Daniel Fagerstrom wrote: And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? It depends on the timeframe for 2.2 ;) I will be offline for the next two weeks (kitesurfing in Mexico :) ) after that I would like to ditch the enviroment abstraction ASAP. So it sounds like 2.2. Hmm, ok, this is a point where I disagree :) I think we should get 2.2 out asap to have our mind clear for new stuff. Of course, you're right that if we plan to develop 2.2 for another year, we can ditch the abstraction as well. But I really fear that in that case we never get 2.2 out. I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. WDYT? Carsten
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Carsten Ziegeler wrote: I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. WDYT? Carsten +1 Ralph
Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Daniel Fagerstrom wrote: >>And for me the most important question :) What is the suggested >>timeframe/version for this? Do you want to do this for 2.2? > > > It depends on the timeframe for 2.2 ;) I will be offline for the next > two weeks (kitesurfing in Mexico :) ) after that I would like to ditch > the enviroment abstraction ASAP. > > So it sounds like 2.2. Hmm, ok, this is a point where I disagree :) I think we should get 2.2 out asap to have our mind clear for new stuff. Of course, you're right that if we plan to develop 2.2 for another year, we can ditch the abstraction as well. But I really fear that in that case we never get 2.2 out. I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler skrev: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. We have had quite a few threads about our problems, so I'm not going to try to find our biggest problem in this thread ;) But one of our problems is that core is monolitic and hard to understand. And this in turn depends on many small complexities that adds upp to overall complexity. One of these problems is th environment abstraction, and that is a problem that I happen to be motivated to atack now. The reason for that is that I want to make the block architecture as independent of Cocoon specifics as possible. And I want to use servlet interfaces instead of our own, but this will require CLI to use servlet interfaces to be able to use blocks. So I wanted to know the communities thoughts about this. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? We can either ave an own extension or better have an extra interface that only contains the extension, then we can check if this extra interface is used in the code. Also we seem to be heading towards making controllers more of a first class citicen in Cocoon, and then we shouldn't force people to handle sitemap specifics in the new controllers. And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? It depends on the timeframe for 2.2 ;) I will be offline for the next two weeks (kitesurfing in Mexico :) ) after that I would like to ditch the enviroment abstraction ASAP. So it sounds like 2.2. /Daniel
Re: [RT] Ditching the environment abstraction
Berin Loritsch wrote: > Carsten Ziegeler wrote: > >> In general I agree with this - it makes learning Cocoon internal a >> little bit easier. But I think the current environment api is not our >> biggest problem. Anyways, our current Request object has more >> functionality as the servlet request object, e.g. to get the sitemap >> prefix and sitemap uri and more important the request attribute handling >> for internal requests. How can we keep this functionality when switching >> to the servlet api? >> >> And for me the most important question :) What is the suggested >> timeframe/version for this? Do you want to do this for 2.2? Or for a >> later version? >> >> Carsten >> > > I would imagine for a leter version. I'd think it would be too soon. > > We have two implementations of the Cocoon environment abstraction: CLI > and WebApp. If we rip out the abstraction now, Forrest would break. I > think that alone would push it out a bit. no, it wouldn't. The servlet api is itself an abstraction. So what we have is an abstraction of an abstraction. The suggestion is to scrap this double abstraction. We could easily have our own CLI implementation of javax.servlet.* That is the suggestion. Regards, Upayavira
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler wrote: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten I would imagine for a leter version. I'd think it would be too soon. We have two implementations of the Cocoon environment abstraction: CLI and WebApp. If we rip out the abstraction now, Forrest would break. I think that alone would push it out a bit.
Re: [RT] Ditching the environment abstraction
In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten Daniel Fagerstrom wrote: > It seem like we all agree about that the Cocoon core need to be > simplified, although we have different opinions about how to achieve it. > IMO it can be done in steps by refactoring of the trunk. > > One of the complications with Cocoon is the environment abstraction: > o.a.c.environment.Request, Response, Context etc. They are similar but > not identical to the javax.servlet and javax.servlet.http interfaces, > which means yet another thing to learn for the user. It also means that > it becomes more complicated to use externally developed components, as > these typically implement the servlet family of interfaces. Furthermore > it leads to a more complicated setup process of Cocoon. > > So, do we need this extra layer of abstraction? It made sense when > Cocoon was mainly a publication framework, for publication the servlet > family of interfaces has a lot of functionlity that is irrelevant. But > now when Cocoon has developed to a webapp framework, it makes much less > sense to have an own abstraction of what already has a standardized > abstraction. o.a.c.e.Request has expanded so that it is close to > identical to HttpRequest. For o.a.c.e.Response and Context there are > larger differences to their servlet counterparts, they are subsets. But > what is not implemented either could be implemented or just throw an not > implemented exception. > > Another reason for having an own abstraction was to be able to use > Cocoon in none servlet environments. This has not happened to any large > extent, in addition to the Http environment, we have CLI, Faces and > Portal environment. For the Http, Faces and Portal environment, using > the servlet interfaces should be a simpilification and improvement. For > CLI, I dont see that it would complicate anything either. > > The main problem with swithing to the servlet interfaces AFAICS, except > for that it takes some work, is back incompability. This could be solved > to some extent by letting our abstactions extend the servlet interfaces. > Nearly all methods have the same names and types. But IMO it would be > better to simplify Cocoon and take the back incompability now and just > remove our own abstraction, we could have some adapter utilities in some > compability block. > > So in a first step I would like to switch our environment abstraction to > their servlet correspondances. > > In an next step I think we should use Servlet instead of processor for > our "controllers": Cocoon, Sitemap, Flow and possibly the Pipeline. This > would make it simpler to reuse Cocoon functionality, and also to > experiment with new kinds of controllers. As discussed before the > Processor interface contains a far to much implementation details that > are connected to sitemap engine internals for beeing suitable as a > general controller interface within Cocoon. > > I'm considering to reimplement the two controllers in the blocks > architecture: the BlocksManager and the BlockManager, as servlets, and > thus get rid of a lot of start up complications. Also it would make it > possible to let a block contain any servlet with a set of components, > instead of hardwiring it to the sitemap controller. > > WDYT? > > /Daniel > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Ditching the environment abstraction
Daniel Fagerstrom wrote: It seem like we all agree about that the Cocoon core need to be simplified, although we have different opinions about how to achieve it. IMO it can be done in steps by refactoring of the trunk. One of the complications with Cocoon is the environment abstraction: o.a.c.environment.Request, Response, Context etc. They are similar but not identical to the javax.servlet and javax.servlet.http interfaces, which means yet another thing to learn for the user. It also means that it becomes more complicated to use externally developed components, as these typically implement the servlet family of interfaces. Furthermore it leads to a more complicated setup process of Cocoon. So, do we need this extra layer of abstraction? It made sense when Cocoon was mainly a publication framework, for publication the servlet family of interfaces has a lot of functionlity that is irrelevant. But now when Cocoon has developed to a webapp framework, it makes much less sense to have an own abstraction of what already has a standardized abstraction. o.a.c.e.Request has expanded so that it is close to identical to HttpRequest. For o.a.c.e.Response and Context there are larger differences to their servlet counterparts, they are subsets. But what is not implemented either could be implemented or just throw an not implemented exception. Another reason for having an own abstraction was to be able to use Cocoon in none servlet environments. This has not happened to any large extent, in addition to the Http environment, we have CLI, Faces and Portal environment. For the Http, Faces and Portal environment, using the servlet interfaces should be a simpilification and improvement. For CLI, I dont see that it would complicate anything either. The main problem with swithing to the servlet interfaces AFAICS, except for that it takes some work, is back incompability. This could be solved to some extent by letting our abstactions extend the servlet interfaces. Nearly all methods have the same names and types. But IMO it would be better to simplify Cocoon and take the back incompability now and just remove our own abstraction, we could have some adapter utilities in some compability block. So in a first step I would like to switch our environment abstraction to their servlet correspondances. In an next step I think we should use Servlet instead of processor for our "controllers": Cocoon, Sitemap, Flow and possibly the Pipeline. This would make it simpler to reuse Cocoon functionality, and also to experiment with new kinds of controllers. As discussed before the Processor interface contains a far to much implementation details that are connected to sitemap engine internals for beeing suitable as a general controller interface within Cocoon. I'm considering to reimplement the two controllers in the blocks architecture: the BlocksManager and the BlockManager, as servlets, and thus get rid of a lot of start up complications. Also it would make it possible to let a block contain any servlet with a set of components, instead of hardwiring it to the sitemap controller. WDYT? The real reason why we wanted to keep the environment pluggable was that we envisioned cocoon as a Mailet as well. Needless to say, this never happened. So, yes, I'd be very happy to get rid of yet-another-servlet-API and simplify things. -- Stefano.
Re: [RT] Ditching the environment abstraction
Il giorno 11/dic/05, alle ore 18:56, Daniel Fagerstrom ha scritto: WDYT? /Daniel Know what? I proposed the same some time ago (I've tried digging out the reference, but couldn't), so a big +1 from me. Ugo
