Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 67459 invoked from network); 2 Feb 2004 09:35:34 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 2 Feb 2004 09:35:34 -0000 Received: (qmail 6309 invoked by uid 500); 2 Feb 2004 09:34:59 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 6113 invoked by uid 500); 2 Feb 2004 09:34:58 -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 Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 6084 invoked from network); 2 Feb 2004 09:34:57 -0000 Received: from unknown (HELO dd2020.kasserver.com) (81.209.148.130) by daedalus.apache.org with SMTP; 2 Feb 2004 09:34:57 -0000 Received: from vafer.org (c-180-220-138.cvx-h.dial.de.ignite.net [62.180.220.138]) by dd2020.kasserver.com (Postfix) with ESMTP id 22E6DB845C for ; Mon, 2 Feb 2004 10:34:38 +0100 (CET) Message-ID: <401E1A72.2090808@vafer.org> Date: Mon, 02 Feb 2004 10:37:54 +0100 From: Torsten Curdt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Future of XSP and ESQL [was Re: An idea - transformer logicsheets.] References: <401D4FE7.10509@o2.pl> <05FE9D5C-54F6-11D8-BA4E-000393D2CB02@apache.org> <401D9969.4010908@mm.st> <401DD148.90800@isisnetworks.net> In-Reply-To: <401DD148.90800@isisnetworks.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N >> But not being the database guy around here, I'm not the one to talk >> about these things so I'll be glad if somebody else wants to come >> forward. >> >> One thing is for sure: XSP is showing its age and we should move >> forward... but without loosing its value. > > Why not pull the ESQL stuff out and provide a stripped down > ESQLTransformer? Something like that sits on my TODO list for ages now. Rrrr! *itch* As soon as I have some spare time... (please don't laugh) Be sure we won't simply deprecate ESQL! My idea is to come up with an unified syntax. Taking the best out of the SQLTransformer and the ESQL logicsheet. Then come up with an ESQL transformer and a logicsheet using the same code base (as much as possible). For an easy migration we could provide an ant task that applies a migration stylesheet. I just hope it's worth the effort since everyone seems to be going the OJB way... We could start a wiki page to collect the best out of both world and come up with the new syntax... WDYT? -- Torsten