From dev-return-79702-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Oct 12 11:52:01 2005
Return-Path:
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 16119 invoked from network); 12 Oct 2005 11:52:00 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 12 Oct 2005 11:52:00 -0000
Received: (qmail 45855 invoked by uid 500); 12 Oct 2005 11:51:58 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 45774 invoked by uid 500); 12 Oct 2005 11:51:57 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
List-Post:
Reply-To: dev@cocoon.apache.org
List-Id:
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 45763 invoked by uid 99); 12 Oct 2005 11:51:57 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 04:51:57 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [130.237.222.115] (HELO smtp.nada.kth.se) (130.237.222.115)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 04:51:59 -0700
X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se
Received: from [192.168.105.132] ([62.84.203.102])
(authenticated bits=0)
by smtp.nada.kth.se (8.12.11/8.12.11) with ESMTP id j9CBpZxu009256
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 12 Oct 2005 13:51:35 +0200 (MEST)
Message-ID: <434CF91A.7070002@nada.kth.se>
Date: Wed, 12 Oct 2005 13:52:58 +0200
From: Daniel Fagerstrom
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Is Cocoon Obsolete?
References: <433EF6D4.6040209@apache.org> <20051002014142.9A7A926D13B@avs2.arnes.si>
In-Reply-To:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
Joerg Heinicke wrote:
>Jaka Jaksic telemach.net> writes:
>
>
>>But even then you realize that accessing the natural functionality (and power)
>>of Cocoon is often very difficult, because there is no obvious API and no
>>function library to access the core functionality.
>>
>>
>BTW, this is the most negative issue with Cocoon at least one person has (I
>don't mean myself and I don't want to speak in his name, so leave him
>anonymous): Cocoon does not really provide an API you can program to. Take even
>such a simple task as accessing session/request/etc.
>
>
Agree about the lack of well defined API. Both in the sense that we
don't mark what is supposed to externally reusable and reasonable stable
interfaces. And in the sense that we have had feature creep in our core
interfaces as Berin showed for Processor.
For session, request etc I think we should migrate to the servlet apis
as I wrote in an other message. Having own interfaces in this area
doesn't make that much sense anymore.
Also having well defined internal APIs will make Cocoon easier to
develop and mantain as it will be easier to understand what is going on.
At some stage I think we should provide a pure API jar that contains the
API that define Cocoon and nothing more. As a first step we could start
to move out component implementations from the core, to make the core
leaner and make it clearer how things are inter related.
/Daniel