On 10/23/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Peter,
thanks so much for this, great plug for me to start.
No problem, I was wired on coffee after a nice long dinner party and
unable to sleep and I had wanted to revive this thread for some
time... Just a couple of comments:
snip/
Peter,
thanks so much for this, great plug for me to start.
Peter Hunsberger wrote:
On 9/30/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
There was a moment where I could have been one of the first people to
respond to this thread, you just happened to ask this question when I
was watching
On 9/30/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
There was a moment where I could have been one of the first people to
respond to this thread, you just happened to ask this question when I
was watching the Cocoon mailing list for some reason or other.
However, in spite of the fact I've
On 14.10.2005 15:07, Vadim Gritsenko wrote:
I do not really understand a helper class as an API. Furthermore it is
not easy. I always have to look up how to write the code.
Decision was made early in 2.0 dev cycle to have objectModel Map as a
contract between Cocoon and components:
That
Joerg Heinicke wrote:
On 12.10.2005 05:01, Vadim Gritsenko wrote:
Take even such a simple task as accessing session/request/etc.
ObjectModelHelper appears several times.
I do not really understand a helper class as an API. Furthermore it is
not easy. I always have to look up how to write
On 12.10.2005 05:01, Vadim Gritsenko wrote:
Take even such a simple task as accessing session/request/etc.
ObjectModelHelper appears several times.
I do not really understand a helper class as an API. Furthermore it is
not easy. I always have to look up how to write the code.
Jörg
On 12.10.2005 13:52, Daniel Fagerstrom wrote:
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
Le 12 oct. 05, à 05:16, Stefano Mazzocchi a écrit :
...I think a better, leaner, cleaner javadoc would go a *LNG* way
to make things easier...
I was thinking about that recently - does anyone know a tool for
tag-based navigation of javadocs?
A better *navigation* of the javadocs, like
...
I was thinking about that recently - does anyone know a tool for
tag-based navigation of javadocs?
A better *navigation* of the javadocs, like being able to see all
classes which have the sitemap generator tags, would help a lot.
Can't you use the refdoc stuff for that? If it's not
On 12.10.2005, at 08:20, Bertrand Delacretaz wrote:
Le 12 oct. 05, à 05:16, Stefano Mazzocchi a écrit :
...I think a better, leaner, cleaner javadoc would go a *LNG*
way to make things easier...
I was thinking about that recently - does anyone know a tool for
tag-based navigation
Le 12 oct. 05, à 09:32, Max Pfingsthorn a écrit :
...Can't you use the refdoc stuff for that? If it's not ready, which I
guess it isn't from the STATUS at
http://svn.apache.org/repos/asf/cocoon/gsoc/rgraham/refdoc/STATUS, I
could take it from where Robert left it...
It's not far from being
Joerg Heinicke wrote:
Jaka Jaksic jaka.jaksic at 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
Jaka Jaksic jaka.jaksic at 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
Joerg Heinicke wrote:
Jaka Jaksic jaka.jaksic at 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
Stefano Mazzocchi wrote:
*my* problem is http://cocoon.apache.org/2.1/apidocs/
Look at it... it's a monster... it includes *everything*. A javadoc is
useless if it's too big to be used as a reference.
Isn't it *meant* to include everything? Isn't it the root idea of javadoc?
Personally I'd
Berin Loritsch wrote:
The Ruby on Rails solution is to use an environment variable that
defaulted to Development. In production the environment variable
would be set on the server to Production. For the unit tests, the
generators automatically run in Test mode. Now, I know that Java 5
On 04 Oct 2005, at 18:08, Stefano Mazzocchi wrote:
Steven and Daniel, I'm sorry, but your comments prove my point.
Sylvain was the only one understanding what this was all about [1]: a
wake up call.
If you emphasize style over content, don't be surprised if people
disregard the latter.
On 03 Oct 2005, at 21:30, Antonio Gallardo wrote:
Great comment, Steven. I feel my self direct addressed with this
statement.
I wonder why you should, really. Quite the opposite, actually.
Now, I know what this work means for other community members.
I think you're doing an ace job
Steven Noels wrote:
...
The same kind of wonder I had when this thread started - as in oh no,
this is sooo easy and self-centered!.
Yes self-centered and irresponsible.
--- o0o ---
Stefano,
We are a large number of people who got inspired of your visions and
have
On 4 Oct 2005, at 10:16, Daniel Fagerstrom wrote:
[...]
You really don't help us.
Are you sure about this? Especially when you say:
[...]
We are a strong community with a great product that is going to be
even greater, we can make it.
The first resource of open-source is ego.
Since
Le 3 oct. 05, à 21:30, Antonio Gallardo a écrit :
...I WASTED not only my last weekend, but a lot of time keeping the
f*** java 1.3 compatibility...
I agree about the *** but anyway, THANKS Antonio for this work.
Keeping 1.3 compatibility for the 2.1.x branch has been a community
decision
Pier Fumagalli wrote:
On 4 Oct 2005, at 10:16, Daniel Fagerstrom wrote:
[...]
You really don't help us.
Are you sure about this? Especially when you say:
[...]
We are a strong community with a great product that is going to be
even greater, we can make it.
The first resource of
Daniel Fagerstrom wrote:
Steven Noels wrote:
...
The same kind of wonder I had when this thread started - as in oh no,
this is sooo easy and self-centered!.
Yes self-centered and irresponsible.
LOL
Steven and Daniel, I'm sorry, but your comments prove my point. Sylvain
was the only one
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Steven Noels wrote:
...
The same kind of wonder I had when this thread started - as in oh
no, this is sooo easy and self-centered!.
Yes self-centered and irresponsible.
LOL
Steven and Daniel, I'm sorry, but your comments prove my
Stefano Mazzocchi wrote:
Stefano,
We are a large number of people who got inspired of your visions and
have spent years on develop and implement them. Some have even built
companies around Cocoon. Now everyone who want to start using Cocoon in
a project, sell products based on it or services
Hi all,
I'll comment on a few snippets of what Stefano said, apart from that I
tend to agree with most of what's been said by others.
Le 30 sept. 05, à 23:57, Stefano Mazzocchi a écrit :
...A phase transition is when you strongly believe in something, then
you strongly change your mind.
Bertrand Delacretaz wrote:
snip/
For me that's where Cocoon is today: more mature, slightly less
exciting, but more capable than ever.
We just have to stay on our toes to keep it fit.
+1.
More thoughts here:
http://www.anyware-tech.com/blogs/sylvain/archives/000217.html
Sylvain
--
Stefano Mazzocchi wrote:
How do you feel about this?
Will Cocoon become obsolete
When will Cocoon become obsolete
would have been more appropriate (albeit less controversial) subjects I
feel.
My thoughts:
(Note: we = the community)
Software = life. If it doesn't evolve it dies.
We have the
Luca Morandini wrote:
Consider: 1) Declining cocoon-users activity.
This worries me as well, especially the last couple of months it has
become very obvious [1].
Why? you might ask:
Is the framework stable? Have most issues been solved/answered already?
Does everything Just Work(tm) and we
Hi,
On 3 Oct 2005, at 12:09, Jorg Heymans wrote:
marketing type=idea
Lets do a video like Rails [2], a picture says more than a thousand
words, a video more than a thousand pictures! WDOT? Can something like
this put us to shame or work in our advantage?
/marketing
*sob* Stop it! Stop it!
Tony Collen wrote:
2. In the 4-or-so years I've been involved with the community, I've
*never* built a production website with Cocoon, and I highly doubt I
ever will. It hasn't caught on here in the states as much as Struts
has, or JSF could. I was holding out hope for a Cocoon type job,
Jorg Heymans wrote:
Luca Morandini wrote:
Consider: 1) Declining cocoon-users activity.
This worries me as well, especially the last couple of months it has
become very obvious [1].
Why? you might ask:
Is the framework stable? Have most issues been solved/answered already?
Does
Jorg Heymans wrote:
Luca Morandini wrote:
Consider: 1) Declining cocoon-users activity.
This worries me as well, especially the last couple of months it has
become very obvious [1].
Why? you might ask:
Is the framework stable? Have most issues been solved/answered already?
Does
Andrew Savory wrote:
*sob* Stop it! Stop it! You're all describing my GT presentation!
ROFL
Here's a sneak preview of the first 30 seconds, without sound:
http://www.luminas.co.uk/andrew/raccoon_first_30s.mov
mighty cool, can't wait to see the rest!!!
Jorg
Andrew Savory wrote:
Hi,
On 3 Oct 2005, at 12:09, Jorg Heymans wrote:
marketing type=idea
Lets do a video like Rails [2], a picture says more than a thousand
words, a video more than a thousand pictures! WDOT? Can something like
this put us to shame or work in our advantage?
/marketing
Jorg Heymans wrote:
Luca Morandini wrote:
often discussed here, very true - as much as we hate (to admit) it
;)
marketing type=idea
Lets do a video like Rails [2], a picture says more than a thousand
words, a video more than a thousand pictures! WDOT? Can something like
this put us to shame
Hi,
On 3 Oct 2005, at 13:18, Sylvain Wallez wrote:
Here's a sneak preview of the first 30 seconds, without sound:
http://www.luminas.co.uk/andrew/raccoon_first_30s.mov
Kewl! If it's based on the 2.2 branch, you may reduce startup time
by adding
Luca Morandini wrote:
4) I liked the Scaffold concept, which we may replicate: not just
samples, but ready-made apps to help people hit the ground running when
developing an app. I mean, we could have a reporting scaffold, or a
These scaffolds can be easily built using m2 archetypes [1].
Luca Morandini wrote:
4) I liked the Scaffold concept, which we may replicate: not just
samples, but ready-made apps to help people hit the ground running when
developing an app. I mean, we could have a reporting scaffold, or a
multi-channel publishing scaffold, or a GIS scaffold (you
curse you CTRL-ENTER!
Jorg Heymans wrote:
These scaffolds can be easily built using m2 archetypes [1]. I'll try
and whip up a basic prototype on my way to the hackathon. If done right
... if done right this could become an easy entry point for first time
users. Rather than downloading
Jorg Heymans wrote:
curse you CTRL-ENTER!
Jorg Heymans wrote:
These scaffolds can be easily built using m2 archetypes [1]. I'll try
and whip up a basic prototype on my way to the hackathon. If done right
... if done right this could become an easy entry point for first time
users. Rather
Luca Morandini wrote:
FWIW, my comments:
1) Videos are great communication tools, and nothing prevent us from
making them, I suppose.
2) This RoR video was good stuff, especially for people building
simple, self-contained apps.
3) I liked the ActiveRecords part, which is something we have to
Sylvain Wallez wrote:
Kewl! If it's based on the 2.2 branch, you may reduce startup time by
adding JAVA_OPTIONS=-Dorg.apache.cocoon.core.LazyMode=true in the
launch script (BTW, should we make this the default?)
IMO Yes. Anything that helps us work more efficiently should be default.
Jorg Heymans wrote:
I'm also thinking about archetypes for popular framework combos, like
CForms/hibernate, Cocoon/Spring, and often used block combos like
portal/, fop/svg and ofcourse asciiart/midi ;)
Hmm... I was thinking more in terms of user-visible functionalities
rather than in terms
Upayavira wrote:
m2 archetype:create -DarchetypeGroupId=cocoon-archetypes
-DarchetypeArtifactId=cforms-hibernate -Dversion2.1.9
And then you stick a pretty UI in front of that, because that command is
likely to frighten the willies out of any Cocoon newbie! :-)
yes, anything that makes
Berin Loritsch wrote:
Sylvain Wallez wrote:
Kewl! If it's based on the 2.2 branch, you may reduce startup time by
adding JAVA_OPTIONS=-Dorg.apache.cocoon.core.LazyMode=true in the
launch script (BTW, should we make this the default?)
IMO Yes. Anything that helps us work more
Luca Morandini wrote:
Hmm... I was thinking more in terms of user-visible functionalities
rather than in terms of underlying technologies.
Look, if one is going to use Spring, he won't be impressed by a canned
app; on the contrary, such a canned app will make a splash on the
average guy
On 03 Oct 2005, at 16:29, Jorg Heymans wrote:
Upayavira wrote:
m2 archetype:create -DarchetypeGroupId=cocoon-archetypes
-DarchetypeArtifactId=cforms-hibernate -Dversion2.1.9
And then you stick a pretty UI in front of that, because that command
is
likely to frighten the willies out of any
Sylvain Wallez wrote:
Agree, but on the other hand, this lazy-loading of components mean that
some buggy declarations will not be detected at startup time, which
would be better in a production environment.
This leads again to the discussion about running modes [1] where some
Ross Gardler wrote:
... a rich client requires higher bandwidth.
This argument absolutely bogus.
Google Maps, for example, is a way richer client than, say, MapQuest but
consumes a fraction of the bandwidth, because using the web in a more
architecturally consistent way, it can take
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Agree, but on the other hand, this lazy-loading of components mean that
some buggy declarations will not be detected at startup time, which
would be better in a production environment.
This leads again to the discussion about running modes
Steven Noels wrote:
IMHO, eye candy, blocks-I'll-commit-rather-than-shepherd-myself and
featuritis without proper consideration and restraint is what is
killing Cocoon. Much of this could be tackled by divorcing the core
from the (figuratively speaking) crap, hard and fast. The good stuff
Stefano Mazzocchi wrote:
Ross Gardler wrote:
... a rich client requires higher bandwidth.
This argument absolutely bogus.
Google Maps, for example, is a way richer client than, say, MapQuest
but consumes a fraction of the bandwidth, because using the web in a
more architecturally
Sylvain Wallez wrote:
Interesting question. If we ship with dev mode on, many people will
deploy in dev mode. On the other hand, if we ship in production mode,
many people won't see the features of dev mode.
Exactly :(
A solution is to ship in dev mode, but ensure that people know
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Interesting question. If we ship with dev mode on, many people will
deploy in dev mode. On the other hand, if we ship in production mode,
many people won't see the features of dev mode.
Exactly :(
A solution is to ship in dev mode,
Sylvain Wallez wrote:
I would (and actually do) use Mappy (http://www.mappy.com/), which has
provided for ages a flash-based GUI that receives vector data from the
server, and which is snappier than GMaps. Bitmaps suck when it comes to
GIS!
Up to a point, Sylvian... if you're talking about
Hi,
On 3 Oct 2005, at 17:04, Stefano Mazzocchi wrote:
I guess you are not aware of this
http://rx4rdf.liminalzone.org/Racoon
Heheh, no I wasn't. I also was unaware of Racoon the dutch rock band,
or racoon the IKE (ISAKMP/Oakley) key management daemon, and
apparently there's a small
Sylvain Wallez wrote:
Interesting question. If we ship with dev mode on, many people will
deploy in dev mode. On the other hand, if we ship in production mode,
many people won't see the features of dev mode.
A solution is to ship in dev mode, but ensure that people know they're
in dev
Luca Morandini wrote:
Sylvain Wallez wrote:
I would (and actually do) use Mappy (http://www.mappy.com/), which
has provided for ages a flash-based GUI that receives vector data
from the server, and which is snappier than GMaps. Bitmaps suck when
it comes to GIS!
Up to a point, Sylvian...
Stefano Mazzocchi wrote:
Ross Gardler wrote:
... a rich client requires higher bandwidth.
This argument absolutely bogus.
Google Maps, for example, is a way richer client than, say, MapQuest but
consumes a fraction of the bandwidth, because using the web in a more
architecturally
Sylvain Wallez wrote:
Luca Morandini wrote:
Sylvain Wallez wrote:
I would (and actually do) use Mappy (http://www.mappy.com/), which
has provided for ages a flash-based GUI that receives vector data
from the server, and which is snappier than GMaps. Bitmaps suck when
it comes to GIS!
Up
Stefano Mazzocchi wrote:
My life regarding software goes thru phases. A phase transition is when
you strongly believe in something, then you strongly change your mind.
Others call it a 'revelation', others think you lost your mind.
I wrote Cocoon as a way to help achieving a more coherent
Steven Noels wrote:
Now, in an environment where every committer/consultant worries about
his own private customers and their JDK version numbers, I wonder if
and when this will ever take off. In an environment where consultants
expect the project to care for the fact they try to make money
Thomas Lutz wrote:
snip/
That's the problem ! You're perfectly right. Every month I have to
re-convince my boss, that it was the right decision to kick out struts
and use cocoon instead. What he tells me is
google around, and you'll find struts, tapestry, turbine in almost
every blog, onjava
On 30.09.2005 23:57, Stefano Mazzocchi wrote:
Over the last 6 months, I worked pretty heavily on Mozilla as a platform.
As you might know I (or we at Virbus at that time) have created an
application built on Mozilla [1] [2].
but most important, is that pretty much everything that cocoon
Joerg Heinicke wrote:
On 30.09.2005 23:57, Stefano Mazzocchi wrote:
Over the last 6 months, I worked pretty heavily on Mozilla as a
platform.
As you might know I (or we at Virbus at that time) have created an
application built on Mozilla [1] [2].
but most important, is that pretty much
Stefano Mazzocchi wrote:
...
The strong architectural parallel between mozilla and cocoon, makes me
very hopeful in the future of mozilla as a platform, even if there are
years ahead of polishing to do.
I also want the GUI executed in the browser, but as many allready have
said, the future
Daniel Fagerstrom wrote:
if we succeed in attracting a large user base,
Are we ?
Consider:
1) Declining cocoon-users activity.
2) Reduced attendance (so far) to GetTogether (and it shouldn't be,
since Amsterdam is a more accessible, if less fascinating, location).
3) Struts being more and
Luca Morandini wrote:
Daniel Fagerstrom wrote:
if we succeed in attracting a large user base,
Are we ?
Consider:
1) Declining cocoon-users activity.
2) Reduced attendance (so far) to GetTogether (and it shouldn't be,
since Amsterdam is a more accessible, if less fascinating, location).
Daniel Fagerstrom wrote:
Luca Morandini wrote:
Daniel Fagerstrom wrote:
if we succeed in attracting a large user base,
Are we ?
Consider:
1) Declining cocoon-users activity.
2) Reduced attendance (so far) to GetTogether (and it shouldn't be,
since Amsterdam is a more accessible, if less
Hello!
I'm not a Cocoon platform developer, but I dare to submit to this
thread, because it sounds rather... depressive.
No! Cocoon is not obsolete!
Cocoon is neither obsolete nor deprecated, except that everyone defines
it to be, by not improving it. Evolution is taking place in domains that
...very interesting RT. I had to wait and sort my thoughts
a bit before responding.
I think your perception of cocoon being kinda 'done'
applies to its general idea. We have shown what is
possible ...but IMO there is left sooo much room for
improvement. They might not be as ground breaking
Hi Stefano:
I am glad to see you again on the list. :-)
2 days ago, I wrote an answer with some of the arguments that other
people already replied to this thread. Between them:
1. Mobile devices taking off -- still a lot of other platforms to
publishing.
2. Nature of software evolution in
Le 2 oct. 05, à 21:02, Antonio Gallardo a écrit :
...I found a new interesting link [3], I didn't check is this is
really an active project.
...
[3] http://cforms-xul.tigris.org/
Sidenote: this is probably related to
http://www.mail-archive.com/dev@cocoon.apache.org/msg31982.html
(still
Bertrand Delacretaz wrote:
Le 2 oct. 05, à 21:02, Antonio Gallardo a écrit :
...I found a new interesting link [3], I didn't check is this is
really an active project.
...
[3] http://cforms-xul.tigris.org/
Sidenote: this is probably related to
One other significant point to the many arguments as to why Cocoon is
*not* obsolete is that a rich client requires higher bandwidth. We tend
to think that bandwidth is limitless and cheap, and to many of us it is
getting that way. However, for a large section of the world, those on
the other
Le 2 oct. 05, à 21:48, Antonio Gallardo a écrit :
Bertrand Delacretaz wrote:
...[3] http://cforms-xul.tigris.org/
Sidenote: this is probably related to
http://www.mail-archive.com/dev@cocoon.apache.org/msg31982.html..
...?? I am clueless. Can you give more hints? :-(
If you look at
Bertrand Delacretaz wrote:
Le 2 oct. 05, à 21:48, Antonio Gallardo a écrit :
Bertrand Delacretaz wrote:
...[3] http://cforms-xul.tigris.org/
Sidenote: this is probably related to
http://www.mail-archive.com/dev@cocoon.apache.org/msg31982.html..
...?? I am clueless. Can you give
Ross Gardler wrote:
One other significant point to the many arguments as to why Cocoon is
*not* obsolete is that a rich client requires higher bandwidth. We
tend to think that bandwidth is limitless and cheap, and to many of us
it is getting that way. However, for a large section of the
On 30 Sep 2005, at 22:57, Stefano Mazzocchi wrote:
How do you feel about this?
Funnny enough, I was thinking about this lately...
Cocoon is not obsolete. It's publishing paradigm, though, is de facto
being obsoletized by a new world of richer clients integrating data
services from
On Monday 03 October 2005 04:11, Ross Gardler wrote:
One other significant point to the many arguments as to why Cocoon is
*not* obsolete is that a rich client requires higher bandwidth.
I agree with Antonio that the above statement is not a fact, but a
circumstance around the particular
Stefano Mazzocchi wrote:
I do that for my latest web sites and the more I learn how to driven the
client, the less I feel the need for advanced server frameworks. Is it
just me?
You describe the revolution from the client side. The other part of the
(r)evolution takes place on the server
Hi,
I think Stefano raises some interesting issues, but there's a flaw in
the premise: is everything we do in Cocoon targeted at a browser-
based client model? I don't think so. It discounts Cocoon as an
integration framework, an XML-based service bus (urgh, buzzword bingo
time), and
I won't reply to this thread until I let more people verbalize their
feelings, but this is OT enough for me to reply now.
Niclas Hedhman wrote:
(Not the mentioning of 'What happened to the RDF promise in Cocoon??')
Are you mentioning the ability to add RDF metadata to our real blocks
(as,
Hi!
I am no Cocoon developer, but I have been working with it, together with my
team, since january, developing a real production application :). So having
written quite a large number of components (or are they services?) and
traced through the Cocoon code countless times, I think I might have
On Sunday 02 October 2005 09:41, Jaka Jaksic wrote:
What I'd like to have
is the ability to split sitemaps into several *files* (not subsitemaps!)
and bind them together with simple include operations. That way you could
split your sitemaps into smaller parts however you wished, and also share
My life regarding software goes thru phases. A phase transition is when
you strongly believe in something, then you strongly change your mind.
Others call it a 'revelation', others think you lost your mind.
I wrote Cocoon as a way to help achieving a more coherent look and feel
for the apache
My life regarding software goes thru phases. A phase transition is when
you strongly believe in something, then you strongly change your mind.
Others call it a 'revelation', others think you lost your mind.
I wrote Cocoon as a way to help achieving a more coherent look and feel
for the
As I am about to leave for the airport I really don't have a lot of time
to respond to this or think much about it, so this is pretty much just a
gut reaction. But in a nutshell, while you ultimately may be right
(although I kinda doubt it) you are certainly very premature. Microsoft
still
On 9/30/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
How do you feel about this?
Stefano,
you always have very interesting RTs. (They're pretty structured, too,
so I wonder if you shouldn't tag them [PT] for Philosophical Thought
or [HT] for Hard Thought.)
I think you're right on your
Very interesting read. As with all inovations, the greatest
achievements are usually the side issues. The SoC, component
frameworks, et al, helped improve the way we think about approaching the
development of software. While that has little to do with web
publication, the contributions to
Stefano Mazzocchi wrote:
snip/
If you ask me, the current infatuation with Ruby on Rails and friends,
while understanding and to the point (the need to avoid XML pushups,
so true), will fail dramatically short in scale to complex systems.
Just like M$ Word is great to write one/two pages and
On Saturday 01 October 2005 05:57, Stefano Mazzocchi wrote:
How do you feel about this?
I think you have a few strong points, as do the others.
When Cocoon first materialized, its concepts were fairly revolutionary and
advanced for its time. IMHO, too much focus on Cocoon has been add this
93 matches
Mail list logo
