Long Term / KDE.org Design Update

[Ken Vermette]

>
> The CDN subdomain is hosted on a completely separate system to most of
> the others.
> It shares server space with download.kde.org and files.kde.org, and
> runs behind Incapsula which provides caching.
>
> You wouldn't be able to do much in the way of dynamic content there as
> a result, as accessing the various databases would be impossible at
> the moment.
> (Out of interest, what are you trying to achieve?)
>

Mainly, one of the things I'd like to do is centralise the javascript and
serve out a general-purpose JSON feed/API from a single subdomain ("
wapi.kde.org", for example); common content which would be digested by all
websites and centrally maintained. The goal being to shift complexity away
from individual systems wherever possible. Then, at most, indivdiual
websites would only need to provide configuration options.

The immediate future would be things like serving out the header and footer
structure as a means to keep all navigations permanently in sync.

As soon as things get centralised, we get to cheaply incorporate useful
dynamic data across all sites, like including release announcement links,
adding trending 'support' topics from the forums, or security advisories. I
know some of these things can be done separately though different APIs, but
having a central abstraction for the disparate systems would centralise
complexity in a maintainable way, make the high-level API much cleaner, and
cut down on requests.

There's other more interesting things than links I would like to include
this way, but having portions of structure be centralised I think is the
first step to maintainability. In the future, I'd like to believe we could
have a Googlish setup where sites share logins, notifications, etc much
more easily. But that'd be further off.

 - Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-www/attachments/20150326/7d5bd37e/attachment.html>