cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [VOTE] Inclusion of SAP R/3 components
Date Thu, 16 Jan 2003 10:14:33 GMT
Christian Haul wrote:

>On 16.Jan.2003 -- 10:03 AM, Sylvain Wallez wrote:
>  
>
>>Steven Noels wrote:
>>    
>>
>>>Other worry: this means adding yet another mega-functional-component 
>>>to Cocoon, and I have have been talking offlist about my worries in 
>>>this direction.
>>>
>>>We better start using the -apps module then, I guess (and some other 
>>>components might as well migrate there, too).
>>>      
>>>
>>I share Steven's feelings (I'm one of the "offlist") : we voted a 
>>cocoon-apps module to host Cocoon-related developments that don't belong 
>>to the core. And this ultra-specific component typically falls in this 
>>category.
>>
>>I don't discuss its quality nor its usefullness (SAP is used in large 
>>companies and this could be a "troyan horse" to bring Cocoon inside), 
>>but adding it to the main CVS repository, even in a block, would 
>>increase the bloat.
>>    
>>
>
>The SAP R/3 connectivity consists of 4 interfaces, 5 implementing
>classes and a transformer:
>
>java/org/apache/cocoon/components/web3/Web3.java
>java/org/apache/cocoon/components/web3/Web3Client.java
>java/org/apache/cocoon/components/web3/Web3DataSource.java
>java/org/apache/cocoon/components/web3/Web3Streamer.java
>
>java/org/apache/cocoon/components/web3/impl/DefaultWeb3StreamerImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3ClientImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3DataSourceImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3DataSourceSelectorImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3Properties.java
>
>java/org/apache/cocoon/transformation/Web3RfcTransformer.java
>
>It is not an application per se but a connectivity
>component. Everything is already nicely organized to fit into a
>block. 
>
>For me, the apps module appeared to be more a repository for stuff
>like wyona e.g. complete apps.
>
>>Please also correlate these thoughts with the "zombie code" discussion.
>>    
>>
>Sylvain, wasn't it you that said if the component were present by
>default, it would have generated patches from the user base? Wouldn't
>that suggest to have it in a highly visible place like core cvs
>module and hence the main distro?
>

What I said is that code becomes zombie if it's not included in the 
distro of the source base that _contains_ the code.

Visibility is another problem, and this is chicken and egg : cocoon-apps 
will be visible if it contains substantial material, and substantial 
material will come in only if cocoon-apps is visible... (same applies to 
cocoondev.org)

Also, we have to consider the size of these components : the Cocoon core 
provides so highlevel and powerful abstractions that adding a 
substantial amount of functionnality in a very specific area requires 
only a few classes. Do 10 classes require a separate project/module ? 
But they clearly don't belong to the core. So what ?

I'm puzzled... (hence the -0.5)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



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


Mime
View raw message