forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] A new Forrest implementation?
Date Tue, 15 Aug 2006 15:50:33 GMT
Tim Williams wrote:
> On 8/15/06, Ross Gardler <rgardler@apache.org> wrote:
> 
>> Tim Williams wrote:
>> > On 8/14/06, Ross Gardler <rgardler@apache.org> wrote:

...

>> > A lot of avalon and excalibur + a very little Cocoon for context and
>> > an (all things considered) wrapped up by a very little bit of Forrest
>> > code.  I'm just suggesting that we've done nothing but wrapped some
>> > stuff here - "forrest technology" is a stretch.  To recreate it, we
>> > could get context elsewhere but we'd need an equivalent to
>> > avalon/excalibur I think.
>>
>> Come on, are you realy claiming that we need Avalon+Excalibur+Cocoon to
>> create a hashmap of possible matches to any given string?
> 
> 
> I'm saying the matching/selection does not come from Forrest code.
> They would need to be implemented.  Source resolution/validity does
> not come from Forrest code; it would need to be implemented.

No we do not need to implement it, we only need to use what is there. 
Here is just one suggestion for each category:

Matching: 	   http://jakarta.apache.org/oro/index.html
Source Resolution: java.net.* and/or HTTPCommons
Source Validity:   http://ehcache.sourceforge.net/

Like I said:

>> All we need is pattern matching followed by a lookup then a lookup. See
>> my psuedo code later in the original post. The *concept* of the
>> Locationmap is Forrest technology and it can be reproduced without any
>> of the baggage Cocoon requires us to bring along.

...

>> I really should have been talking about the complexitites of writing a
>> generator. As we very rarely need to write transformers. Try writing a
>> generator that, for example, uses hibernate to communicate with a
>> relational database.
> 
> 
> Same thing, except it's just a producer and not also a consumer.  The
> code to do this will be almost exactly the same in any other
> SAX-event-streaming approach.  But anyway...

You provide the code for a hibernate generator. But have you tried 
deploying it in Forrest. Like I said nothing is as simple as you seem to 
think. Just try it - writing code is easy - *using* it is hard.

>> > I think being in some sort of managed environment (e.g.
>> > Spring) is likely needed in any real-world approach.  So I'd turn this
>> > around and ask where is the complexity?
>>
>> First complexity: building Cocoon
>>
>> Second complexity: building any component that has additional 
>> dependencies
>>
>> Third complexity: deploying a new (non-trivial) component within a plugin
>>
>> Fourth complexity: a community that is pulling in many different 
>> directions
>>
>> There are many more but I will leave it at that. If you don't agree then
>> I suggest you actually try it before arguing the case. You can then tell
>> me where I am going wrong.
> 
> 
> "Actually try" what?  Surely you can be more constructive than
> questioning my credibility here?

See above.

I'm not intending to question your credability as an individual, I am 
questioning whether  you have actually tried to deploy a non-trivial 
Forrest application.

My point is that if it is not reasonably simple the vast majority of 
coders will go an easier route (I have and I have been around Cocoon and 
Forrest for about 5 years now).


>> I disagree. The sitemap is a way of *configuring* this complex
>> processing, it is not the processing itself. The sitemap has become an
>> XML programming language and I hate it for that reason.
>>
>> Have you ever dived in to the implementation and tried to do anything
>> useful in there?
> 
> 
> Again, what implementation?  I've looked inside to the Treeprocessor
> code in Cocoon, yes, and it is difficult to grasp.  I did this when
> doing the LM mounting stuff to see how mountnodes were implemented in
> the sitemap - I like to think this was useful.  I see no reason why
> the average user would care about this stuff though.

The "average user" is not who we should be targeting, we are a 
publishing framework not a publishing tool. We need developers.

On the other hand, if we really are targetting users then we should 
consider whether they have the resources and access to install a 
monolothic web application to do simple publishing. My experience is 
that they don't

So we are not attracting developers because of the complexity of the 
code we are built on and we are not attracting real users because they 
cannot deploy the code. The root cause of both problems, in my opinion, 
is the same.

>> <map match="foo/bar/**">
>>    <aggregate>
>>      <location src="..." required="true"/>
>>      <location src="..." required="false"/>
>>    </aggegate>
>> <map>
> 
> 
> Fair enough, move the aggregation to the Locationmap.  This looks very
> similar to the sitemap though, no?

Yes, that is one part of the sitemap that we need (there are others). I 
don't intend to claim it was an improvement, only illustrate that we do 
not need the sitemap to do it. There are many other ways we could do it, 
I'm only providing examples for this RT.

It's also worth noting that doing the configuration in this way removes 
the indirection between the sitemap and the locationmap, which is a nice 
side-effect.

>  I am not disagreeing with
> the performance problem itself.  For example, I think a much larger
> contributing factor is that we re-generate everything for changes that
> really impact only a small part of a site.  This has nothing to do
> with Cocoon baggage; we just have an implementation that isn't very
> efficient.

This *is* a Cocoon problem, we've been looking at ways to solve it for 
many years and we can't becuase Cocoon gets in the way. See the 
archives. In fact this is another strong argument for using

>> >> Ready Made Transformations
>> >> --------------------------
>> >>
>>
>> ...
>>
>> > You seem to be
>> > suggesting that Cocoon requires some big overhead to do transforms and
>> > that's simply not the case.
>>
>> That's right, I call 40Mb of bloat a fair big overhead for doing XSLT
>> transformations.
>>
>> This time I really am oversimplifying, but I hope you see my point -
>> certainly that is how my customers see it. As a result I ended up, in
>> most cases, writing a series of Java components that I wired together
>> manually and plugged directly into whatever framework they were using.
>> This RT is about doing this in a more felxible and reusable way.
> 
> 
> You're customers are likely just intimidated by the
> Cocoon-learning-curve itself rather then 40Mb of jar files.  

I think I know my customers pretty well. When they can write a 
transformation in about 5 lines of code with a couple of megs of jars 
they don't even get past the 40Mb dowload.

However, you are right, for those that do get past the download, they 
are intimidated by the learning curve and chaotic implementation of Cocoon.

>> > I'm struggling to figure out what you think is forcing us into our
>> > current apparently overly complex solution.  Is it the sitemap grammar
>> > that is complex?
>>
>> Not the grammar itself (although I do hate the fact that we are now
>> programming using the sitemap). The complexity is in processing of that
>> gramar whic results in the selection of the processing path to take.
> 
> 
> I don't understand.  Treeprocessor? NodeBuilders? Matchers?

We want to do input->transformation->output

We do not need treeprocessors and nodebuilders (along with much of the 
other sitemap stuff).

>> >> Conclusion
>> >> ----------
>> >>
>> >> Cocoon does not, IMHO, bring enough benefits to outweigh the 
>> overhead of
>> >> using it.
>> >>
>> >> That overhead is:
>> >>
>> >> - bloat (all those jars we don't need)
>> >
>> >
>> > this is going to be addressed with maven (argghhh) and/or osgi someday
>> > - it's a recognized issue by many cocooners.
>>
>> "someday" is the optimal word there. I've been waiting too long.
> 
> 
> C'mon, you're an OS veteran here.  Patches welcome, right?

Right, and where are the devs to create those patches? Why are they not 
here? I think I've made my view on this pretty clear.

Why am I not patching Cocoon? Because I don't think it will be time well 
spent. I don't use it outside of Forrest and I don't use Forrest 
commercially anymore because I don't believe it is the right framework 
for my needs.

Am I alone in this view? Maybe, this RT will tell me. If I am alone then 
of course, Forrest should continue and...

>> If we reject this RT based on this argument then I want to see Forrest
>> developers helping Cocoon sort this out rather than standing by waiting
>> for it to happen.
> 
> 
> Ok, I threw the "maven" thing in with fingers crossed.  I'd rather
> they go back to ant personally, maven is silly.  I have a high-speed
> connection and it takes forever to download libs each time I *attempt*
> to build only to see it fail 10 minutes into it.  Argghhh...

I feel your pain, and I'm in total agreement, but the Cocoon devs need 
to hear it rather than the Forrest devs. Right now Cocoon is fairly 
split on this point.

> Again, strictly talking about the components, what you describe above
> as a "plugin" is an implementation of XMLProducer and XMLConsumer.
> I'm not seeing the benefit/difference but don't waste time on
> responding until I actually put the effort into looking at your
> psuedo-code.

I'm not sure why you keep raising this XMLProducter/XMLConsumer point. 
I've never said anything about losing it, I've always said it is good 
and we should keep it, but we don't need to keep all that Cocoon is just 
for that little bit of good stuff.

Looking at the pseudo code won't help here as it didn't cover this 
aspect as I'm not really talking about changing the how the information 
flows internally, I'm talking about the rest of the baggage that plugs 
it all together.

Ross

Mime
View raw message