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