[OpenAFS] New OpenAFS website proposal.

[Jakub Witkowski]

2010/11/25 Harald Barth <haba@kth.se>:
>
>> > Certainly it seems functional; What's the backend? The current web
>> > site, being emitted,
>> > has the advantage that we could clone it around the world simply by
>> > pointing numerous web servers
>> > at the content in AFS.
>
> Which kindof is a big plus because most of the folks involved with AFS
> know how a AFS backend works.
>
>> The site is based on Plone ( http://plone.org/ )
>
> I was afraid to hear that, some webadmin some time ago chose it for
> the contents of www.pdc.kth.se and I really have learned to hate it.

This sounds like you have Plone 2.x (or even worse, 2.x upgraded to 3.x) ar=
ound!
Things have changed for the better since that time, fortunately :)
>
> * It is a kindasorta web server, but a dumb one, so it needs an apache
> =C2=A0anyway to front it.
Yes, but that's the burden of pretty much any web application these
days. Zope's server has matured immensely over the years and is now
robust enough to be exposed to the internet - although I keep it
behind nginx running as a virtual host redirector.
>
> * It has some content management backend (zope?) which so far noone has
> =C2=A0managed to reallt learn, so every upgrade is a 'do we dare' nightma=
re
>
I've been managing Zope and Plone instances for several years now; I
know it can be a pain to upgrade.

> * The only way I know to get content into it is the horrible builtin edit=
or.
>
Zope (and Plone) has had WebDAV based "external editor" functionality
since time immemorial; however it's often hidden from users for
"security reasons".

> * There is a markup language, but as noone knows if you can do that parti=
cual
> =C2=A0thing in the markup language and it is difficult to find out, peopl=
e
> =C2=A0write HTML anyway.

HTML is *preferred* markup language for content in Zope/Plone. If you
are developing new *products* (i.e. add-ons), then yes, it's important
to know Page Templates and Python, but that is not necessary to use
the portal.

>
> * I don't know how to get content out again.
>
Depends on content type and how the site in question was constructed.
(and what you want to do with it later!)

> * It has builtin user management and what you see depends on if you
> =C2=A0are logged in or not (the articles have states, like "published"
> =C2=A0which are not visible for everyone), for me this results in an
> =C2=A0login-logout-login work cycle.
>

The whole idea of "content management" revolves around being able to
selectively publish content from the pool you have.
Version by version, Plone is becoming simpler to use (and comprehend)
in this particular area.

> * We still have bugs like "can not see version history" which we have
> =C2=A0not figured out (well, we are not a web shop, but OpenAFS is neithe=
r).
>
Not having seen the portal in question I cannot help :-)

>> which is a Python
>> powered content management system. The downside to this solution is
>> that it requires a long-running process and a bit more resources than
>> classic "bunch of php" would use and needs a slightly more exotic
>> configuration in the frontend web server.
>
> The CPU cycles are not a problem today.
>
>> On the upside, it is
>> self-contained and requires little more than modern gcc and svn to
>> clone the whole site.
>
> As the OpenAFS web site does have very little interactive content and
> all the people who contribute know how to edit a file in AFS, I'd
> recommend a setup which builds on these skills, maybe with some "make
> && make install" which does checks and builds the menu and does a vos
> rele.
>
It's quite possible to make a build script that will automatically
pull down content from some repository and add it to a fresh Plone
site.

The reason behind my choice of CMS was that it would allow many people
working together on the content without each and every of them needing
direct access to the underlying storage, which should help improve the
content in the long run - for example, it would be much easier to
update documentation to match current code, simply because the
developer working on a given feature can directly edit the pertinent
document without having to deal with website innards.

> # All this does not mean that we do not need a refurbished web site.
>
In the end, the real question is, do we have a dedicated person (or
group) that are documentation writers and each and every change to
official manuals must pass under their fingers or do we want to do it
in a more opportunistic, more distributed way?
A non-interactive web site naturally lends itself to the former, while
a more interactive one will help foster the other.

> # Appearence is of course made with css, CMS or not.
>
> Harald.
>

Jakub.