Dain Sundstrom wrote:
On Aug 24, 2006, at 7:41 AM, Hernan Cunico wrote:

anyway, web site authoring aside, what are the benefits of moving all the cwiki content, just a change in the URL? what is the issue if we have pointers back and forth on both sites?

Um what do you mean by "moving all the cwiki content"?

I thought I saw a trend for moving content over the main web site (KB, maven, ...). Anyway, just my perception.

Anyway, we use cwiki to edit our main site, the internal URLs need to point to geronimo.apache.org or all of our web traffic will end up on the cwiki server and infra will be very upset.

Yup, but we are not discussing where to host the web site. As I said in the previous note, "... I think that the effort of authoring the web site ( just the web site ) is worth pursuing ..."


Just as an example, we initially had the FAQ on the web site (well, had others in the old wiki and spread out throughout the documentation), then we created a KB space in confluence and consolidated all FAQ into that space. Why take it back to geronimo.apache.org/KB? In the web site there is a link on every single page pointing directly to the KB in the cwiki.

IMO, it would be best if we exported the KB space and rewrote the internal urls to be within geronimo.apache.org. This would keep the KB traffic on the main apache server.

Do we know how much traffic we have over the KB space now, both view and edit?

I don't really see the benefit of moving the space into the main site, I think it is more a personal preference than any other thing, I'm cool with that.

The way I (personally) see it is that we develop the content on Confluence and we have it autoexported there. We point to it from every single page on the main web site, so my question is why should we move it? The only thing I see is a change in the URL


Back to the web site authoring, let's assume we have access to the file system. We would have to copy all the autoexported HTML somewhere else, fix all the links and images ( the autoexport plugin has some "issues" ) and then put it into the svn repository. Once there, we all know the procedure to get it published. One thing to keep in mind is that we would not have the site's source versioned in svn, rolling back from backup may not be an easy tasks.

If we can get cwiki to check the existing content into svn, we can use the following steps:

1) cwiki: write static html
2) cwiki: svn commit changes to https://svn.apache.org/repos/asf/geronimo/site/cwiki
2) zone*: svn update https://svn.apache.org/repos/asf/geronimo/site
3) zone: rewrite cwiki urls
4) zone: svn commit changes to http://svn.apache.org/repos/asf/geronimo/site/trunk/docs
5) www: svn update http://svn.apache.org/repos/asf/geronimo/site/trunk/docs

This is basically what goopen does to create the xbean site. Except the first 5 steps all happen on the goopen server.

* zone is our apache geronimo zone server

see the "Access to cwiki filesystem" thread on infra.


I think that the effort of authoring the web site ( just the web site ) is worth pursuing and I'm more than willing to contribute to find a more elegant solution for developing the web site.

It would be great if we can all agree on what content belongs to the wiki and what content belongs to the web site ( dynamic vs. static ).

If we have the system above, there is no need to make this type of distinction anymore, and we will be able to use powerful tools like snippit on our main site (see http://geronimo.apache.org/xbean/editing-custom-xml.html)

Note sure I follow, we would still have the main site and the cwiki. My point was for us to determine what content is static enough to go directly into the web site and what content is not along with the ability to promptly edit any content.

Is there any other space, other than KB and obviously SITE, that we would like to serve directly from the main site?

Cheers!
Hernan


-dain


Reply via email to