cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <jheini...@virbus.de>
Subject Re: Cocoon website outdated.
Date Sun, 05 Oct 2003 07:43:45 GMT
Hello Antonio,

Antonio Gallardo wrote:
> Hi:
> 
> The news page at: http://cocoon.apache.org/news/index.html
> It does not show there is a 2.1.2 release!

this page has to be maintained. It's in 
cocoon-site/src/documentation/content/xdocs/news/index.xml and there is 
no problem updating it.

> I will be glad to update all the site, but since I dont know the mechanics
> to update the site. I prefer to don't touch it at all.
> 
> It would be a good idea to show how to do that. I know there is a
> "cocon-site" and a "cocoon-2.1" in the CVS, but don't know where the
> forrest source to generate the site really resides. I also search on
> maillist and nowhere is info about that.

http://wiki.cocoondev.org/Wiki.jsp?page=CocoonWebsiteUpdate

> If I assume the lastest sources are at "cocoon-2.1", then the site is
> really outdated compared with what there is. There are many changes in
> documentation and others pages in cocoon-2.1 that are not showed to the
> average user. Now I understand posts from some users telling us there is
> no documentation. Yes, It is, but in the distribution.

http://cocoon.apache.org/1.x/** is in cocoon-1 module
http://cocoon.apache.org/2.0/** is in cocoon-2.0 module
http://cocoon.apache.org/2.1/** is in cocoon-2.1 module
http://cocoon.apache.org/<anything else> is in cocoon-site module

> People like me (too lazy), first prefer to read some docs in the website
> before download and give a try. If this is true, then we are losing
> potential users. I know you can tell me: "We don't need users" or similars
> assertion. At the end this is not the point of the discusion.
> 
> Some other outdated pages I saw are:
> 
> http://cocoon.apache.org/changes.html
> http://cocoon.apache.org/history.html
> http://cocoon.apache.org/whoweare.html
> http://cocoon.apache.org/news/index.html

They can all be updated. As long as it's the cocoon-site module there is 
no problem

> Mainly, there are still the old site for 1.0 and 2.0. I understand the
> nostalgia for the old good times. ;) But I think we can delete the old
> site or update it or better move the old site to "Cocoon classics site".
> That way we can avoid current problems as some contradictory statements.
> For example:
> 
> Check the definition of what is cocoon in 1.0: http://cocoon.apache.org/1.x/
> vs. what is written here: http://cocoon.apache.org/2.1/
> 
> This is a total diference! Then what is cocoon at all?

Where is the problem with different definitions for Cocoon 1.x and 2.1? 
They had different goals.

> I think similar conflicts are there in the site. I think it is problematic
> for some people understand what cocoon is at all. We are not stating clear
> what is Cocoon! References can be taken from both since they are oficial
> statements from the Cocoon project.
> 
> The worst case is if a users check definitions at: 1.0 and 2.1 and said:
> "Well, I prefer 1.0, because I need a publisher framework. I don't want
> 2.1, because it is a webapp framework".... and we are not supporting more
> 1.0. Poor potential user.

2.0 should have a similar definition to 1.x. OTOH there are better "pure 
publishing frameworks" like Forrest.

> I know this is a very hard work to be done to reorganize the website. I
> propose to create an old release menu where this old sites can reside (if
> we choosed to saved it for the history).

I see no need.

> 2. WHAT WE NEED?
> 
> I saw the lastest post from Carsten that shows us a lack in updating the
> website:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106508923825397&w=2

It's because of the restructuring and we will wait til 2.2 module exists.

> That show we need a better publishing mechanism. I don't try to said
> forrest is bad here. I love forrest. The answer can be a RFE to forrest to
> be able to update just the changed HTML files. I don't know is this is
> posible at all, but by the the generated cocoon site with 62.6 MB, we saw:

It's possible in theory, because you can "build site" on your local 
machine and commit only the pages you want to update. But there is still 
the menu, which would have completely broken, if you update only a few 
files.

> 1.0 site: 1.2 MB
> 2.0 site: 22.9 MB
> 2.1 site: 36.7 MB
> 
> If we assume:
> 1-We are not changing at all the old sites.
> 2-The site surely will grow, because we are documenting the project.
> 3-The 2.1 will become "historic" with the next 2.2 release. Adding more
> almost 37 MB to "unchanged files".
> 
> Then we need to:
> 1-Avoid reposting the same files over and over.
> 2-Allow committers update just the changed files easily. That way the site
> will be more dynamic than it is right now.

Tomorrow and the day after tomorrow we will discuss this too. (Not only) 
Stefano has a vision of a best of two worlds: simple as wiki (WYSIWYG 
editing like Linotype), structured as XML (Linotype). We will see what 
comes out of the hackathon, but you know in which direction it will go: 
Linotype :-)

> I just tried to show some of the problems we have with the Cocoon website
> and what we can do to solve this. This is an open discussion. Please
> comments what we can do in this area.

Enough comments ?? ;-)

Joerg


Mime
View raw message