incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: [www] html instead of markdown (mdtext)?
Date Fri, 12 Aug 2011 15:50:03 GMT

On Aug 12, 2011, at 8:15 AM, Rob Weir wrote:

> On Fri, Aug 12, 2011 at 10:10 AM, Shane Curcuru <> wrote:
>> (To provide a little context while Gav may be asleep)
>> On 8/12/2011 9:26 AM, Rob Weir wrote:
>>> On Fri, Aug 12, 2011 at 3:41 AM, Gavin McDonald<>
>>>  wrote:
>>>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<>
>> ...snip snip snip...
>>>>> Just a thought:  Could you do the entire website in MediaWiki, with only
>>>>> exception cases (download page, etc.) done in HTML?
>>>> Just to put a blocker on this right away, we will not be using the wiki
>>>> as the
>>>> main website or the main entrance into the OOo world.
>>> Since it is not self-evident to me why a wiki would be a problem for
>>> the main website, could you explain this a little further?  Is there a
>>> technical problem?  Remember, the wiki already comprises several
>>> thousand pages of website content, so in a very real sense the "main"
>>> website is already the wiki.
>> Performance.  As I understand it, the bulk of all content is
>> served statically as html files.  Putting a major project's homepage website
>> like the future office.a.o (or whatever name) up as a wiki would add a
>> significant amount of load to our servers, even for a highly efficient wiki
>> engine.
> Thanks, that gives some context.  So "main" in this case is not
> necessarily only the top level page, i.e., an eventually
> or the current    Certainly
> those pages would be some of the most highly-trafficked pages.  But we
> probably have some others that are also, FAQ's,  Release notes,
> download page, etc.

Yes, anything that is currently in the Kenai part of the is considered to be

> But that still leaves the long tail of the thousands of other pages
> that are individually accessed rarely, but may add up to significant
> load.

Yes, a lot of pages that will need to be inspected. This is true no matter where these pages
end up - the website, a wiki, or the bit bucket. This will include proper IP treatment.

> I'm surprised there is no caching mechanism for MediaWiki to simply
> write out up static versions of pages and then invalidate the cache
> for a particular page when it is changed.  In theory you could have
> the rarely-changed pages be just as efficient as static HTML.  Plugins
> exist that do this for WordPress, for example.

It is certainly likely that we will move pages between the Wiki and the CMS. We need to be
further along with the framework before we can understand the details of converting the Wiki
Markup to either MDText or HTML and the reverse.

Some project's export their site from the Confluence Wiki - on look
for the directories with a small "x". But then the style and framing is still an issue.

>> The beauty of the CMS is that while it's easy to work on the pages (either
>> via SVN or browser), the final result is simply checked into SVN and then
>> the resulting .html file is just stuck on the production webserver site.
>>  Some projects use a wiki to manage their homepages (i.e. project.a.o,
>> separate from any community wiki they may have), but the physical homepage
>> that end-users see is typically static html that's been exported from their
>> wiki site.
>> Gav or infra folk can provide more details, but you should plan on adhering
>> to whatever performance restrictions the infra team requires for the main
>> website.

We will be looking towards making the most static site possible. If we want a dynamic front
page then I believe the republish frequency is one hour. This is how
is made "dynamic".

View raw message