Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B03CF94.9457FDCF@anyware-tech.com>
Date: Thu, 17 May 2001 15:18:12 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Issues left for going beta
References: <990082235.3b0374bbf12d5@mail.otego.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Giacomo Pati a �crit :
> 
> Dear Developers
> 
> Most of the developers on Apache Cocoon 2 are willing to produce the first beta
> very soon. I'd like to collect the showstopper issues remaining.
> 
> A few days ago Carsten proposed the 18th of May for a beta date. No one objected
> it but there are still issues left and my time left to do it at the moment is
> really sparse.
> 
> The recent discussion about Parameter forced me to have a look at all the
> interfaces that belong to sitemap component. I've found that we need to vote on
> the following topic.
> 
> a) Does a Matcher need to be parameterized and thus need to expand the match
> method of the Matcher interface with Parameters?
> 
+1 if it makes sense. If parameters are not available where it makes
sense, someone will inevitably need it one day. So the sooner the
better...

> b) The same issue is true for Selector as well. Does it need it, too?
> 
Same as above.

> The discussion and voting about moving the <parameter> element into the map
> namespace will block the beta release until it's done because this is a change
> of the sitemap syntax/semantic and we cannot do it afterward because it will
> break backward compatability. I know that it will not be a trivial change to
> whoever will patch the sitemap.xsl file because of some code optimation done
> there based on namespace tests (see my recent response to Marcus Crafters
> question about those tests).
> 
If the vote is finished, I'll do it : I originated this and have some
experience in namespace matters in XSL ;)

> Another issue is the production of the dists. I've made some test yesterday
> evening and found that it is very huge (about 18M). After analysing it I've seen
> that the source dist has all the jar twice in it. Once int the ./lib and once in
> the ./webapp/WEB-INF/lib directory. How can/Should we reduce it?
> 
Libs are about 7.5 Mb (15 if doubled) : Cocoon is bundled with many
external libs and this is a perfect example of it's strength for
integrating other components/technologies, including JSP and VBScript :)
These libs should stay bundled with Cocoon to show its power and avoid
endless "where can I find xxx.jar to use the xxxProducer ?" on the users
list.
About the duplication, couldn't the build copy the jars from ./lib to
./webapp/WEB-INF/lib ?

> Also there is no "binary dist" target in the build.xml yet. Well, this might not
> be a issue for the beta-1 release.
> 
> A few week/month ago we discussed about standardizing the namespaces we use in
> C2. The general pattern we agreed upon was:
> 
>    http://apache.org/APPLICATION/FOOBAR/VERSION
> 
> Where APPLICATION is either "cocoon" for cocoon centric applications or "xsp"
> for logicsheets, FOOBAR is the name of the application concern and VERSION is
> another pattern describing the version of the application in the form
> major.minor which are both positive integers. There have been ports of
> logicsheets from C1 which don't respect this normation. Should we change those
> namespaces to the pattern above or have new ones (with similar or equal
> functionallity) sometimes after going beta?
> 

Will we have to support old namespaces if they're not changed before
beta ? If yes, then change them now to avoid supporting old ones.

> Ah, the new (the old has this as well IIRC) I18nTransformer uses a parameter
> named src to specify the dictionary to use. I think it should be consistent with
> all sitemap components that such values are best specified in the src attribute
> of the transform element:
> 
>    <map:transform type="i18n" src="dictionary.xml"/>
> 
> And also do we realy need two of them? Are they in such a way different from
> each other to legitimate this?
> 
> As I've said in the beginning of this mail my time is very limited these days
> and thus I cannot propose a date for the beta because I cannot predict when the
> issues listed here will be fixed/realized. The 18th of May is tomorrow, so it
> will not be realizable (uh, another Avalon interface ? :). We can shift it from
What about the Shiftable interface ? :)
> week to week but this doesn't makes any fun. For me and most of you this is a
> unpleasant situation but it doesn't makes any sense to define a date for going
> beta without seeing it really possible to make.
> 

People will start using Cocoon as it is (sitemap, logicsheets, bundled
components, etc), before extending it with their own components and thus
depend on the internal APIs. So IMO, we should solve logicsheet and
sitemap namespace issues before beta (doesn't seem to be hard work), and
as Carsten seems to need a beta quickly, we can delay after beta passing
parameters to matchers and selectors if this requires more time.

Oh, and what about the recent cache issues : are they solved ? IMO they
should be before beta.

> So, your comments and votes :)
> 
> Giacomo
>

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