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