Hello everyone.
You might know that we are starting to think about \’Capacity 2.0\’, aka \’the
future of kde websites\’.
Here is what we have in mind. This is pure brainstorming, although i think
many of us share the same vision.
1) Content/Logic seperation.
Currently, Capacity has no seperation between anything. Its spaghetti php
code mixed with html which containts logic, view AND data.
With Capacity 2.0, we want to have a properly written CMS which stores data in
a database. We also want an MVC approach to ease and organize development.
2) No more seperate instances for each application.
Currently, if you want a website for your application, you have to ask
sysadmins for a kde.org subdomain. You should also \’commit\’ your websites files
(as mentioned in 1st issue, content, view and logic are in simple php files) to
svn/git.
This approach has a BIG flaw:
Its HARD. Setting it up is hard. Updating it is hard. Changing it is hard.
Thats why there are so many outdated kde.org subdomains. Of course, some
people have an awesome attitude. For example Okular people have their website
updated, but Pino and Albert are exceptions. Most capacity based kde.org
subdomains are outdated (specially those which belong to an application)
Most KDE developers do not even have a LAMP stack installed. They checkout their
website\’s source, change some dirty html and commit. Then they refresh the
webpage to see what has changed.
We are going to create a single webapp which contains all data: One site to
rule them all.
3) Dedicated to applications.
As we said, we are going to create a single website which contains all data.
But you probably dont want your application to be \’just another page\’ of
kde.org, right? You want your (sub)domain to be dedicated to your application.
Dedicated to your application.
We are going to handle this. We want your application\’s page to be dedicated
to your application, while being a part of kde.org. we will also have
<appname>.kde.org stuff handled as well.
4) Flexibility.
Of course there is one bad thing about using a cms or something like that: You
lose flexibility. With current capacity, you can just commit your html stuff.
With new approach, you couldnt.
So, the cms will HAVE to be very much flexible to satisfy your needs.
5) Revisions.
Good thing about current setup? We can blame you. We can see what you commited
and we can YELL at you.
We dont want to lose this feature. CMS will have to track whatever, whoever,
whenever does it. And will have to be able to revert easily.
6) Multilingual. It has to be. Do i have to explain?
7) ACL\’s. Another good thing about using svn to manage websites is that we
have acl\’s to know who has access to which website. Now that we are going to
have a single site to rule them all, we need advanced ACL\’s.
8 ) Integration. It needs to interact with identity.kde.org for authentication
and user data, projects.kde.org to understand project\’s, repositories,
managers and other info. OCS and KNewStuff intergration could all be done.
Those are the core points. If you have others to add, please feel free to reply and make it happen.
Note, a rewrite is seriously needed for the ease of maintenance, so this is not necessarily about keeping the current way or not.
It is about improving the whole kde web experience.
This post is written with collaboration of Ingo Malchow and Sayak Banerjee. Special thanks to both.
