cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: GSoC
Date Fri, 16 Mar 2007 21:57:09 GMT
Daniel Fagerstrom napisaƂ(a):
>>> And finally some more project ideas:
>>>  a) cleanup input modules: IIRC there was some discussion about
>>>     reducing the number of input modules in favor of one that uses an
>>> expression
>>>     language that works on a well-defined object model.
>>>  b) cleanup expression language usage throughout Cocoon
>>>     Daniel, do you have any pointers?

Wow, lots of reading; luckily weekend has just started. Thanks! :)

>> I would add even one more:
>> * refactoring of pipeline stuff
>>   While working on improving HTTP-compliance of pipelines I had a
>> feeling (expressed in few comments) that pipeline code really needs
>> major redesign and refactoring. Current code is really obscure,
>> hard-to-follow and full of hacks. It's really a challenge to make a only
>> minor change in it being sure that nothing is going to break. Situation
>> is even worse, that there are only few tests provided for pipeline code.
>> My idea was to write lots of tests _before_ doing any refactorings
>> covering all the code in pipeline module and start reimplementing
>> classes with effort to not change APIs too much. However, small changes
>> would be needed IMHO.
> Just refactoring something sounds a little bit boring. I think you 
> should add something also. One idea would be to make pipelines usable 
> outside Cocoon sitemaps. I started to work on it 

>  But one still need to depend on the cocoon-core module. It would be 
> much neater to just need to depend on the cocoon-pipeline-impl.
I think that refactoring would lead to cleaner contracts and lesser 
amount of dependencies. Maybe I misunderstand "refactoring" word. Is 
what I'm talking about mor a redesign?
>> Also, I wonder if it's even doable in two months as this
>> changes would involve lots of discussion and the task in general is
>> really challenging.
> As a refactoring consists of a sequence of behavior preserving 
> transformations you can stop in any moment, so it is of course doable 
> in two months or in any given period of time ;)
> A possible problem with doing it during the summer is that the list 
> might be less responsive. So it requires that you are confident enough 
> to make some tough decisions without that much feedback.
Thanks for bringing this. After thinking it over I agree that summer is 
not good time for such a task. It would involve lots of question about 
design decision made in the past and about those are going to happen etc.
It means that I think it's not good candidate for GSoC project but I do 
not abandon the idea in general. If time permits I will return to this 

Grzegorz Kossakowski

View raw message