cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: evolution [was Re: Back from Germany]
Date Mon, 04 Nov 2002 16:43:00 GMT
> Since I know I wouldn't have been able to do it alone (Cocoon1 was done 
> by myself alone and we saw where that went :), I think it's the entire 
> dev community that did the cocoon design.

:-)  How many of us can say that any of their first version systems are even
running long after version 2 hits the streets?  It seems that many people
still use C 1 and depend on it (and some even seem to miss it when
confronted with C2!)

>> If I was to ask a random Cocoon developer to tell me the architecture 
>> of Cocoon I'm not sure I could get a coherent picture.  
> 
> Hmmm, have you ever tried?

Directly, only with my own staff (some of whom we hired for their Cocoon
experience). People can elucidate on generators, transformers, serializers
and actions.  After that things get "interesting"... Outside of my group, we
see people confused about which parts of Cocoon do what on the mailing list
all the time. So far it's mostly XSP versus everything else, but there's
also confusion around Sunshine, authentication and related pieces.  The
input modules discussion seems to be mostly focused at the moment, but then
again it's new.  Once it hits the streets I can see questions on it vs.
XSP/logic sheet oriented approaches and when to code things as site map
logic vs. outside of the sitemap. etc.

>> There's a lot of pieces to Cocoon, many of them overlap and some run 
>> counter to each other.
>
> Really? like what? 

Maybe it's just me, but I perceive a lot of the XSP support as influencing
pieces of the core Cocoon architecture in ways that I don't think would have
necessarily happened if Cocoon they had happened later instead of earlier in
it's life cycle.  As such, a lot of the parameter handling, and sitemap
handling seems to be slightly twisted in ways that don't seem completely
natural to me.  Now, that's likely because I expect XSLT to be purely
declarative.  However, the mix of programming models that Cocoon supports
seems to result in some problems.  

I started to go into more detail here, but I really don't think the existing
code has many problems that can't be solved (and I don't want too much
thread creep); my real worry is in the future when the Cocoon community
starts to grow much bigger.

> Yes, there is some amount of overlap, but I think 
> this is natural in an architecture designed with a darwinistic 
> metodology (as we do).

Yes, the overlap is pretty natural with any system that has had more than
one person work it; I spent part of last week ripping 2 redundant methods
out our system over and over again (they where propagated all the way
through from the EJBs to the front end, sigh).  

>>   As
>> such, it's not clear that Cocoon currently has a complete architecture 
>> (some
>> of that seems due to V1 compatibility issues).  Certainly the work 
>> that you
>> are doing now seems to be helping to rectify that.
>
> I really can't resonate with your vision on this, but I respect it. May 
> I ask you how long have you been experiencing how we do software design 
> around here? (I'm not being ironic, just curious)

I've been working with Cocoon for about a year now.  I joined the dev list
in Sept.   I did my first collaborative design work over 20 years ago...

>>
>> I guess what I would changes is that I would add  "architecture", "more
>> discussion" and "design" steps between discussion and implementation, and
>> architecture and design would also be single person efforts.  Not for
>> everything, but for the large pieces.
> 
> All right. We might just be arguing on terminology here.

Yes, mostly I think so.

>>
>> I think that you are doing this to some extent, but I think it would 
>> help to make it explicit.  
>
> what do you want me to make more explicit? the process or the 
> discussions? sorry, it's not clear and I don't want to get you wrong.

Everything...  what I'd really like to see is 1) a complete documented
strategic vision for Cocoon (as far out as you can push it); 2) a documented
way for people to contribute to that vision (perhaps a sort of
architect/designers FAQ?);  3) architecture and design specs for all the
major Cocoon pieces, both anything already in Cocoon that is considered
strategic and anything coming down the pipe that you see as strategic.

You did say that you work on Cocoon 24 hours a day, 7 days a week, right?

>> The big thing that seems to be missing is the
>> documentation that would fall out of the architecture and design pieces.
> 
> Holy cow. I remember spending several *days* writing these sum-up docs 
> and sending them to the list. Yeah, some of them are still named [RT] to 
> begin with, but they were later used as references for writing the 
> implementation.

Ahh, but the list isn't where they belong; they belong in the Cocoon
documentation, on the Web pages, right up front where a developer can't help
but bump into them!  If you do a search on architecture on the archives you
get over "500" messages between now and the start of 2001. Search on
"design" and it's over 1600 matches. Even a search on "Strategy" gets over
100 matches.  Where to start?  The threads go on forever, the discussion is
disjoint and hard to follow (it bounces between threads).  Mailing lists are
great resources, but in themselves they shouldn't be relied on to serve up
documentation.

>>
>> Even if it's not complete it at least gives a framework into which the
>> overall documentation can be pieced together.
> 
> Hmmm, I don't think that linux has this architectural documentation (or 
> at least, I never saw one) yet you seem to implying that linux' design 
> model is better than cocoon's. Or am I misunderstanding you here?

Linux does have pretty good architectural documentation (there are entire
books devoted to it and if you do a Google search for something specific
you're likely to find it). But I don't think Linux's design model is
particularly better than Cocoon (it seems more or less the same);
developmentally Linux is a very hard thing to come to grips with.  However,
Linux does have many good API doc's and good strategy docs (there are also
many missing pieces, but it's a lot bigger).

>> >
>> >No, I think Cocoon proves that open development can be a killer way to
>> >do both research and development and, if run correctly, is not an ideal
>> >but a practical solution.
>>
>>
>> Again, I'm not so sure.
>
> You are not sure that open development can be a killer way to do both 
> research and development if run correctly?

Well at the extreme, I'm afraid so.  I've just seen too much design by
committee to be comfortable with it.  It might work for a while, but as the
projects grow things get out of hand.

>> Adding blocks will help keep things organized, but now, people will 
>> look at
>> the default configuration and think "hmm, I would like to also have this
>> function" and throw something out, not realizing that it is already
>> implemented (perhaps in a completely different way than they imagined) in
>> some other block.  I'd really like to see people such as yourself try and
>> keep a firm control of the overall architecture.
>
> From my side, I'll do everything I can *NOT* to do this :)
>
> Why? simple, I think this community is way smarter than I can possibly be.

I think you underestimate yourself!  (Remember, the collective intelligence
of any group is inversely proportional to square of the number of members of
the group :-)  Seriously, I'm not too worried;  it's just that I've been
down this path many times before and I've seen what happens if someone
doesn't keep pushing a singular vision.

>>   I guess that also implies
>> going to the effort of documenting it, and I can understand why that
might
>> not be as attractive of option as having the "list" (so to speak) be the
>> documentation... ;-)
>
> Any effort to take those emailed sum-up documents and tranform them into 
> XML stuff that we can add to the documentation will be well accepted.

Yes, I knew that would come up; sooner or later I hope to do something in
this regard.  (If I could only get a handle on the Cocoon architecture I'd
have a place to start ;-)

> but keep in mind that if you are not able to do software design on a 
> mail list, you won't be helpful for this project. Community autofiltering.

I can live with the list; hopefully the list can live with me: I have very
specific things I need to get out of the data to presentation transformation
process.  So far Cocoon is the best match for a generalized framework that
I've found.

>>
>> Just in case I haven't made it explicit, I do admire the work that you
and
>> all the rest of the Cocoon developers have done to date.  I also 
>> believe you
>> haven't seen anything yet in the terms of the size the Cocoon community
>> could grow to.  
> 
> Yeah, hopefully so. That's why blocks will make it possible to 
> parallelize development on top of cocoon completely, reducing the 
> development pressure on top of the cocoon core.

Yes, I think so.  The main thing I want to do could be almost completely
done as a block.  It might need one or two core hooks (in particular I need
parameter passing fixed), but not much else.

>> There's a fine line between collaboration and anarchy and
>> someone, such as yourself, is going to have to help keep watch over 
>> the masses.
> 
> Yep, I agree. Hopefully we'll be able to scale better when cocoon will 
> not only be modular inside but also from a usability perspective.

I'll drink to that...

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message