You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/03/15 22:54:54 UTC
The road to Cocoon 2.1
I would like to see Cocoon released as soon as possible, but not sooner.
There are a few things to do before we can release and there are two realms:
1) internal -> things inside the distribution
- flow
- finish polishing the object model
- provide a block-like method for extension of the object model
- write a block-like modular system in the build for
- flow
- xsp
- actions (yet to be agreed upon)
- instrumentation (yet to be understood how)
- finish cleanup the samples
- write the distribution targets in the build
- decide how we want to distribute the software
2) externals -> things outside the distribution
- move the web site over to cocoon.apache.org
- move the mail lists
Anything else I've missed?
Re: The road to Cocoon 2.1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 16/03/2003 10.29:
> Jeff Turner wrote:
>
>> On Sat, Mar 15, 2003 at 06:09:44PM -0500, Tim Myers wrote:
>>
>>> I usually just lurk...
>>>
>>>
>>>> - write a block-like modular system in the build for
>>>> - flow
>>>> - xsp
>>>> - actions (yet to be agreed upon)
>>>> - instrumentation (yet to be understood how)
>>>
>>> Can't this wait until a 2.1 point release? It is a major change but
>>> doesn't
>>> involve interface changes from what i gather of the most recent
>>> discussion on the sitemap (actions and flow). XSP (from a packaging
>>> POV) is nothing more than a group of components. I don't see that
>>> factoring these things out is
>>> a prerequisite to a 2.1 beta or even final.
>>
>> I agree.
>
>
> Oh, that's no problem for me.
>
> Carsten, you propsed the move: what's your feeling about this?
One note from me:
These "refactorings" have their importance, but I agree that they are
not a necessary prerequisite to an alpha release, but they are to a
final release.
For flow and xsp, if anyone wants to try it, just give a notice ahead of
time and do it; the build is just a copy of the blocks one with a change
in the directory name.
For Actions, I don't think we really object in having them pluggable (on
the basis that if I can use them, it's ok), but it would also be nice to
do it in a more comprehensive manner, discussing how to make distro
customization more pluggable. I have a couple of ideas, but we'll have
to see it together.
Then we have instrumentation... which relies on a package that IIUC is
not released. Well, it's darn cool, but it also introduces a dependency
someone might not want. ATM I'll just leave it, because it does produce
interesting data for performance measurement, and I'd also like to see
it as part of our daily performance tests.
I have here also an idea of how to deal with this, a sort of poor man's
concern weaving... ok it's simple, just add every "concern" as comments,
and have a preprocessor "weave" them in.
For example:
//@instrument(what to do)
//@log(what to log)
//@assert(what to check for)
/*@instrument
more instrumentation code
*/
In this way we can insert commands *without* needing to compile them if
we don't want to. We can also use different instrumentors or loggers
with the short form, as long as they understand the abstract semantics.
The problem here is that this needs a filtered copy, which many have
loved to hate... but if we can enhance the compiler to use our version
of the filesystem that does this on the fly, no copy is needed.
I still have to work on this, but I'm starting to like it :-)
Ok, back to the mail.
I'd add to the above modules all the environments. Are you all ok if I
move them too (last time you "all" were it seems)?
Ciao :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: The road to Cocoon 2.1
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten Ziegeler wrote:
<snip/>
>
> For 2.1 we have some additional points in our todo list in cvs
> that have to be solved before a final release.
There is also the document at:
http://xml.apache.org/cocoon/plan/release.html
<snip/>
--------------------
Version 2.1 Beta 1
* apply patches
* test flowmap + docs + etc
* documentation to be published by Forrest
* finish the document "Updating Cocoon" which
describes the major changes since 2.0.2
* finish the refactoring of samples
* finish to move scratchpad stuff in main trunk
* more tests and examples on the flowmap.
* Move complete Source implementation to Excalibur
* Change implementation for SitemapConfigurable
--------------------
By the way, that "refactoring of samples" item was
talking about refactoring the old samples. Now we
need to finish refactoring the refactoring, and ensure
that we do not lose the remaining original samples that
were not yet refactored. Phew.
--David
RE: The road to Cocoon 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> > For 2.1 we have some additional points in our todo list in cvs
> > that have to be solved before a final release.
>
> Bring them on.
>
>From the todo.xml (perhaps some of them are obsolete; perhaps some are not
so
important):
<action context="code" assigned-to="CZ">
Redesign the SitemapConfigurable handling.
</action>
<action context="docs" assigned-to="open">
For 2.1: Attend to any high+ issues in the
<link href="plan/todo-doc.html">Documentation To Do List</link>
</action>
<action context="code" assigned-to="open">
For 2.1: use (only) released versions of excalibur (xml, source, store
etc).
This requires a release of those components in excalibur.
</action>
<action context="code" assigned-to="open">
Complete (means put everything we know of into even if it has to be
commented) the cocoon.xconf file and put descriptions into it
</action>
<action context="build" assigned-to="open">
Complete (means put all allowed constructs and combinations)
the lint/sitemap.xmap file. Enhance the RELAX NG grammar for sitemap.
</action>
<action context="code" assigned-to="SW">
For 2.1: Views must start not from the first encountered label, but from
the last one
(see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101784499622172&w=2
)
</action>
<action context="code" assigned-to="NKB">
For 2.1: Make comprehensive samples with the handle-errors sitemap and
real world
use cases. Add also specific Selector and a FaqBuilder to be used by the
as a NotifyingBuilder.
</action>
<action context="code" assigned-to="SW">
Change the handle-errors to enable use of any Generator.
DOUBLE CHECK THAT REDIRECTS ARE FORBIDDEN.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102633389301850&w=2
</action>
<action context="code">
Remove all useless blank strings in XSP-generated code that hinder
performances.
This should be configurable (through an attribute?) to be able to keep
them when
needed.
</action>
<action context="code">
For 2.1: Make a guide on how to upgrade Cocoon, and see how this can be
eased.
</action>
<action context="code">
For 2.1: Redesign FragmentExtractorGenerator/Transformer so that it works
on a clustered
server : store fragments in the session rather than in a local store.
<br/>
</action>
Carsten
Re: The road to Cocoon 2.1
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>Oh, that's no problem for me.
>>
>>Carsten, you propsed the move: what's your feeling about this?
>>
>
> Ok, I think moving actions and xsp is not necessary as they
> were included in 2.0 already anyway.
> 2.1 is the first release with flow, so moving this into a block
> before it's released makes sense for me, but I agree that
> delaying the release only because of this, makes no sense.
>
> We can move it into a block painlessly after 2.1, so agreed let's
> add in on our list for 2.2.
Good.
> For 2.1 we have some additional points in our todo list in cvs
> that have to be solved before a final release.
Bring them on.
Stefano.
RE: The road to Cocoon 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> Oh, that's no problem for me.
>
> Carsten, you propsed the move: what's your feeling about this?
>
Ok, I think moving actions and xsp is not necessary as they
were included in 2.0 already anyway.
2.1 is the first release with flow, so moving this into a block
before it's released makes sense for me, but I agree that
delaying the release only because of this, makes no sense.
We can move it into a block painlessly after 2.1, so agreed let's
add in on our list for 2.2.
For 2.1 we have some additional points in our todo list in cvs
that have to be solved before a final release.
Carsten
Re: The road to Cocoon 2.1
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeff Turner wrote:
> On Sat, Mar 15, 2003 at 06:09:44PM -0500, Tim Myers wrote:
>
>>I usually just lurk...
>>
>>
>>> - write a block-like modular system in the build for
>>> - flow
>>> - xsp
>>> - actions (yet to be agreed upon)
>>> - instrumentation (yet to be understood how)
>>
>>Can't this wait until a 2.1 point release? It is a major change but doesn't
>>involve interface changes from what i gather of the most recent discussion
>>on the sitemap (actions and flow). XSP (from a packaging POV) is nothing more
>>than a group of components. I don't see that factoring these things out is
>>a prerequisite to a 2.1 beta or even final.
>
>
> I agree.
Oh, that's no problem for me.
Carsten, you propsed the move: what's your feeling about this?
Stefano.
Re: The road to Cocoon 2.1
Posted by Jeff Turner <je...@apache.org>.
On Sat, Mar 15, 2003 at 06:09:44PM -0500, Tim Myers wrote:
> I usually just lurk...
>
> > - write a block-like modular system in the build for
> > - flow
> > - xsp
> > - actions (yet to be agreed upon)
> > - instrumentation (yet to be understood how)
> Can't this wait until a 2.1 point release? It is a major change but doesn't
> involve interface changes from what i gather of the most recent discussion
> on the sitemap (actions and flow). XSP (from a packaging POV) is nothing more
> than a group of components. I don't see that factoring these things out is
> a prerequisite to a 2.1 beta or even final.
I agree.
--Jeff
> Tim
Re: The road to Cocoon 2.1
Posted by Tim Myers <ph...@pirouline.sts.jhu.edu>.
I usually just lurk...
> - write a block-like modular system in the build for
> - flow
> - xsp
> - actions (yet to be agreed upon)
> - instrumentation (yet to be understood how)
Can't this wait until a 2.1 point release? It is a major change but doesn't
involve interface changes from what i gather of the most recent discussion
on the sitemap (actions and flow). XSP (from a packaging POV) is nothing more
than a group of components. I don't see that factoring these things out is
a prerequisite to a 2.1 beta or even final.
Tim
Re: The road to Cocoon 2.1
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> I would like to see Cocoon released as soon as possible, but not sooner.
>
> There are a few things to do before we can release and there are two
> realms:
>
> 1) internal -> things inside the distribution
>
> - flow
> - finish polishing the object model
> - provide a block-like method for extension of the object model
-0
> - write a block-like modular system in the build for
> - flow
> - xsp
> - actions (yet to be agreed upon)
> - instrumentation (yet to be understood how)
-0
> - finish cleanup the samples
+1
> - write the distribution targets in the build
> - decide how we want to distribute the software
+1
> 2) externals -> things outside the distribution
>
> - move the web site over to cocoon.apache.org
+1
> - move the mail lists
+0
> Anything else I've missed?
I am agreeing with the general feeling we should release real soon now,
although I personally don't have a pressing need. I'm happy living off
CVS HEAD for quite some time.
I find it strange however to see XSP/Actions/Flow being lumped together.
XSPs and Actions have been out there and used for quite some time -
whether we like that or not - and moving them from the 'core' to some
outside module will break the current usage pattern (not technically
perhaps, maybe just in spirit).
For some reason or another, you indicate there's a liaison between these
three 'components', and feel like they should be treated equally. I
personally don't know.
Another way to move forward is to step back in time, and postpone
releasing _any_ flow-related stuff until we hashed out everything. That
way, stuff that people have been asking for gets finally released, and
we buy ourselves some time to work on the flow and how it integrates
with the sitemap.
I don't think we should release anything flow-related before there is
*some* real documentation on it.
<dreaming-mode>And if the flow is that great, it might as well warrant a
version 3.0 release.</dreaming-mode>
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: The road to Cocoon 2.1
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> I would like to see Cocoon released as soon as possible, but not sooner.
<snip/>
>
> Anything else I've missed?
*) Ensure that the new entity resolver works on all platforms.
We need people to test this on all platforms.
http://marc.theaimsgroup.com/?t=104736924600002
*) Fix 'build test'
This should never be broken or it gives a very bad
impression for Cocoon.
--David
Re: The road to Cocoon 2.1
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> On 15/3/03 21:54, "Stefano Mazzocchi" <st...@apache.org> wrote:
>
>
>>- flow
>> - provide a block-like method for extension of the object model
>
>
> What about something similar to Mozilla's XPConnect?
>
> http://www.mozilla.org/scriptable/
No, I don't think this is what we need. XPConnect is a dynamic wrapper
between native XPCOM components and javascript that avoids the use of a
IDL compiler to pregenerate the code hooks.
What we need is a way for a block to *extend* the FOM.
One way of doing this, would be to avalonize the flow environment, write
an XML configuration for the FOM and have blocks 'xpatch' that
configuration file which is used at startup by the flow environment to
write the flow.
But I'm not sure how hard this is to implement.
Stefano.
Re: The road to Cocoon 2.1
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 15/3/03 21:54, "Stefano Mazzocchi" <st...@apache.org> wrote:
> - flow
> - provide a block-like method for extension of the object model
What about something similar to Mozilla's XPConnect?
http://www.mozilla.org/scriptable/
Pier
Re: The road to Cocoon 2.1
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 15/3/03 21:54, "Stefano Mazzocchi" <st...@apache.org> wrote:
> - flow
> - finish polishing the object model
Working on getting the IDL polished and improved... Sorry for being absent
this week, but had some issues and work and my dad's visiting me for the
first time in 4 years! (family inversion-of-control first!)
Pier