You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Kay Schenk <ka...@gmail.com> on 2011/08/11 18:12:15 UTC
[www] html instead of markdown (mdtext)?
I am proposing that we adopt plain HTML for the OOo website instead of
the current markdown (mdtext) implementation.
I hesitate to make this recommendation given ALL the time and research
Dave and others have already spent on the current incubator website,
but, I feel, given that we will be migrating a rather large existing
site, it makes sense.
I also realize that doing this will "break" the ability to use the
webgui editing capability of the Apache CMS, forcing everyone to use svn
for page updates. However, I don't have a good feel right now for the
ultimate impact of that -- e.g. what do we expect in terms of web site
editors.
This would allow us to continue to use the default template system
(Dotiac::DTL) but eliminate the need for wrapping or intermixing
markdown text with normal HTML. HTML files shouldn't require any
"wrapping" functions at all I think, since this is the indigenous format
for web servers. We would have to bypass header, footer and navigation
items for anything that *isn't* html, like js, css files.
Unfortunately, I've had a very difficult time this week trying to find
any information on the setup details of Dotiac::DTL (documentation not
available) -- the relationship of the two .pm files to the template
areas, etc.
I took at look around at many the Apache web areas (svn) at:
http://svn.apache.org/repos/asf/
You will see, as I did, that the vast majority are not using markdown,
and this is NOT a requirement.
Anyway, thoughts/comments on this proposal?
--
------------------------------------------------------------------------
MzK
"Those who love deeply never grow old;
they may die of old age, but they die young."
-- Sir Arthur Pinero
Re: [www] html instead of markdown (mdtext)?
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Aug 11, 2011 at 2:41 PM, Terry Ellison <Te...@ellisons.org.uk>wrote:
> Kay,
>
> Surely this is looking at the issue the wrong way around. HTML is a lower
> lever of abstraction. Yes, this suggestion makes life easier for the
> maintainer but at the expense of extra complexity/difficulty for the
> contributor -- especially as the average contributor isn't at ease working
> in HTML, so will tend to use some form of WYSIWYG editor. Hence different
> editors can end up laying out the HTML completely differently if they use
> different tools to do this, so an svn differencing of two successive
> versions with minor content changes could end up looking entirely different.
>
> If we are going to HTML then perhaps it might be appropriate on this
> project to mandate the use of the OOo web editor for editing all such
> content. Just a thought.
>
Terry--
Folks that have been maintaining areas of the OO.o website in the past have
used HTML. So, I don't think the barrier would be any different now if we
chose this, instead of Markdown, for the site. Plus, we need to import a LOT
of pages, ALL in html, that we simple can NOT convert to markdown.
Dave indicated the Apaches CMS gui tool also works with html, so I will play
with this to see what's it's like.
> Regards Terry
>
>
> On 11/08/11 19:55, Kay Schenk wrote:
>
>> On Thu, Aug 11, 2011 at 10:13 AM, Dave Fisher<da...@comcast.net>
>> wrote:
>>
>> On Aug 11, 2011, at 9:12 AM, Kay Schenk wrote:
>>>
>>> I am proposing that we adopt plain HTML for the OOo website instead of
>>>>
>>> the current markdown (mdtext) implementation.
>>>
>>> We can mix and match.
>>>
>>> yes, but... mdtext is converted to html anyway. I just think the
>> overhead --
>> i.e. maintenance by existing and "new" folks -- will be unweildy.
>>
>>
>> I hesitate to make this recommendation given ALL the time and research
>>>>
>>> Dave and others have already spent on the current incubator website, but,
>>> I
>>> feel, given that we will be migrating a rather large existing site, it
>>> makes
>>> sense.
>>>
>>> Don't worry about me. What I've learned is useful to me even if we decide
>>> to take another approach.
>>>
>>> How do you propose handling all of the Kenai wrapping?
>>>
>>
>> uh...I'll be honest...I am not familiar with the " Kenai wrapping". And I
>> dare say, probably few are. My *guess* is this in invovled in
>> headers,footers, and ????
>>
>> We might be able to ignore whatever this is and just get on with something
>> WAY simpler for the time being.
>>
>> The new site won't be registering users and probably doesn't need a lot of
>>
>>> the current *.vm and *.html.html files.
>>>
>>> I also realize that doing this will "break" the ability to use the
>>>> webgui
>>>>
>>> editing capability of the Apache CMS, forcing everyone to use svn for
>>> page
>>> updates. However, I don't have a good feel right now for the ultimate
>>> impact
>>> of that -- e.g. what do we expect in terms of web site editors.
>>>
>>> You really CAN edit HTML using the Apache CMS Web-Gui. It is just that I
>>> currently like unwrapped body html.
>>>
>>> Oh--OK -- I hadn't tried this and this isn't what the web page about the
>> CMS
>> indicates.
>> So, even better.
>>
>>
>>
>>> This would allow us to continue to use the default template system
>>>>
>>> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
>>> text with normal HTML. HTML files shouldn't require any "wrapping"
>>> functions
>>> at all I think, since this is the indigenous format for web servers. We
>>> would have to bypass header, footer and navigation items for anything
>>> that
>>> *isn't* html, like js, css files.
>>>
>>> In the back of my head this week I've been thinking about a way to use
>>> properly formed html and then "rewrap" to apply consistent headers and
>>> footers is forming. The idea is to use an xslt filter to extract html
>>> from
>>> the<head> and<body>.
>>>
>>> Well this may be super but unfortunately I am not knowledgable enough to
>> really know what you're saying here. But isn't this the purpose of the
>> template system -- to just patch on the headers, footers, anythng else?
>> Again, I am thinking "project long-term". I think it's vital to put
>> something in place that the regular web-jockey is familiar with.
>>
>>
>> For the head - grab various elements including scripts and style. For the
>>> body grab it all. There are at least two advantages:
>>>
>>> (1) Each html page can be separated and tested outside of site framework.
>>> (2) Every html page published on the site automatically has the proper
>>> framework.
>>>
>>> Unfortunately, I've had a very difficult time this week trying to find
>>>>
>>> any information on the setup details of Dotiac::DTL (documentation not
>>> available) -- the relationship of the two .pm files to the template
>>> areas,
>>> etc.
>>>
>>> It took me sometime to understand how it works. If you follow the
>>> instructions on running locally - website-local.mdtext - it ought to
>>> work.
>>>
>>> OK--I still have NOT done that. The thing is the instructions still do
>> NOT
>> give details on the setup of Dotiac::DTL. If I installed that locally,
>> maybe
>> some documentation would emerge. And I will do that. There's LOADS of info
>> on django -- but not this perl wrapper.
>>
>>
>> Perhaps we should IRC tomorrow and we can identify the disconnect in this
>>> documentation.
>>>
>>> uh--sorry, I'm unavailable tomorrow. I think YOUR documentation is fine
>> really for what you're trying to get people to do -- with dealing with
>> mdtext. But, this is kind of my point.
>>
>> *IF* we went straight html, and *IF* the templates were setup and fixed in
>> place -- yes, we'd need a perl/django wonk for this aspect (along with
>> some
>> MUCH better documentation on this aspect) -- folks wouldn't have to do a
>> local setup at all. They'd simply edit HTML and commit the way we've
>> always
>> done in the past. Much simpler in my mind.
>>
>>
>> I took at look around at many the Apache web areas (svn) at:
>>>>
>>>> http://svn.apache.org/repos/**asf/ <http://svn.apache.org/repos/asf/>
>>>>
>>>> You will see, as I did, that the vast majority are not using markdown,
>>>>
>>> and this is NOT a requirement.
>>>
>>> It is not a requirement, it was a recommendation. (POI uses a very old
>>> version of Forrest and no one has wanted to change...)
>>>
>>> Anyway, thoughts/comments on this proposal?
>>>>
>>> Let's see if others have something to say. (I've got some Fortran and SQL
>>> to do today.)
>>>
>>> yes, good idea...have fun with your project
>>
>>
>> Regards,
>>> Dave
>>>
>>> --
>>>> ------------------------------**------------------------------**
>>>> ------------
>>>> MzK
>>>>
>>>> "Those who love deeply never grow old;
>>>> they may die of old age, but they die young."
>>>> -- Sir Arthur Pinero
>>>>
>>>
>>>
>>
>
--
---------------------------------------------------------------------------------------
MzK
"Those who love deeply never grow old;
they may die of old age, but they die young."
-- Sir Arthur Pinero
Re: [www] html instead of markdown (mdtext)?
Posted by Terry Ellison <Te...@ellisons.org.uk>.
Kay,
Surely this is looking at the issue the wrong way around. HTML is a
lower lever of abstraction. Yes, this suggestion makes life easier for
the maintainer but at the expense of extra complexity/difficulty for the
contributor -- especially as the average contributor isn't at ease
working in HTML, so will tend to use some form of WYSIWYG editor. Hence
different editors can end up laying out the HTML completely differently
if they use different tools to do this, so an svn differencing of two
successive versions with minor content changes could end up looking
entirely different.
If we are going to HTML then perhaps it might be appropriate on this
project to mandate the use of the OOo web editor for editing all such
content. Just a thought.
Regards Terry
On 11/08/11 19:55, Kay Schenk wrote:
> On Thu, Aug 11, 2011 at 10:13 AM, Dave Fisher<da...@comcast.net> wrote:
>
>> On Aug 11, 2011, at 9:12 AM, Kay Schenk wrote:
>>
>>> I am proposing that we adopt plain HTML for the OOo website instead of
>> the current markdown (mdtext) implementation.
>>
>> We can mix and match.
>>
> yes, but... mdtext is converted to html anyway. I just think the overhead --
> i.e. maintenance by existing and "new" folks -- will be unweildy.
>
>
>>> I hesitate to make this recommendation given ALL the time and research
>> Dave and others have already spent on the current incubator website, but, I
>> feel, given that we will be migrating a rather large existing site, it makes
>> sense.
>>
>> Don't worry about me. What I've learned is useful to me even if we decide
>> to take another approach.
>>
>> How do you propose handling all of the Kenai wrapping?
>
> uh...I'll be honest...I am not familiar with the " Kenai wrapping". And I
> dare say, probably few are. My *guess* is this in invovled in
> headers,footers, and ????
>
> We might be able to ignore whatever this is and just get on with something
> WAY simpler for the time being.
>
> The new site won't be registering users and probably doesn't need a lot of
>> the current *.vm and *.html.html files.
>>
>>> I also realize that doing this will "break" the ability to use the webgui
>> editing capability of the Apache CMS, forcing everyone to use svn for page
>> updates. However, I don't have a good feel right now for the ultimate impact
>> of that -- e.g. what do we expect in terms of web site editors.
>>
>> You really CAN edit HTML using the Apache CMS Web-Gui. It is just that I
>> currently like unwrapped body html.
>>
> Oh--OK -- I hadn't tried this and this isn't what the web page about the CMS
> indicates.
> So, even better.
>
>
>>
>>> This would allow us to continue to use the default template system
>> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
>> text with normal HTML. HTML files shouldn't require any "wrapping" functions
>> at all I think, since this is the indigenous format for web servers. We
>> would have to bypass header, footer and navigation items for anything that
>> *isn't* html, like js, css files.
>>
>> In the back of my head this week I've been thinking about a way to use
>> properly formed html and then "rewrap" to apply consistent headers and
>> footers is forming. The idea is to use an xslt filter to extract html from
>> the<head> and<body>.
>>
> Well this may be super but unfortunately I am not knowledgable enough to
> really know what you're saying here. But isn't this the purpose of the
> template system -- to just patch on the headers, footers, anythng else?
> Again, I am thinking "project long-term". I think it's vital to put
> something in place that the regular web-jockey is familiar with.
>
>
>> For the head - grab various elements including scripts and style. For the
>> body grab it all. There are at least two advantages:
>>
>> (1) Each html page can be separated and tested outside of site framework.
>> (2) Every html page published on the site automatically has the proper
>> framework.
>>
>>> Unfortunately, I've had a very difficult time this week trying to find
>> any information on the setup details of Dotiac::DTL (documentation not
>> available) -- the relationship of the two .pm files to the template areas,
>> etc.
>>
>> It took me sometime to understand how it works. If you follow the
>> instructions on running locally - website-local.mdtext - it ought to work.
>>
> OK--I still have NOT done that. The thing is the instructions still do NOT
> give details on the setup of Dotiac::DTL. If I installed that locally, maybe
> some documentation would emerge. And I will do that. There's LOADS of info
> on django -- but not this perl wrapper.
>
>
>> Perhaps we should IRC tomorrow and we can identify the disconnect in this
>> documentation.
>>
> uh--sorry, I'm unavailable tomorrow. I think YOUR documentation is fine
> really for what you're trying to get people to do -- with dealing with
> mdtext. But, this is kind of my point.
>
> *IF* we went straight html, and *IF* the templates were setup and fixed in
> place -- yes, we'd need a perl/django wonk for this aspect (along with some
> MUCH better documentation on this aspect) -- folks wouldn't have to do a
> local setup at all. They'd simply edit HTML and commit the way we've always
> done in the past. Much simpler in my mind.
>
>
>>> I took at look around at many the Apache web areas (svn) at:
>>>
>>> http://svn.apache.org/repos/asf/
>>>
>>> You will see, as I did, that the vast majority are not using markdown,
>> and this is NOT a requirement.
>>
>> It is not a requirement, it was a recommendation. (POI uses a very old
>> version of Forrest and no one has wanted to change...)
>>
>>> Anyway, thoughts/comments on this proposal?
>> Let's see if others have something to say. (I've got some Fortran and SQL
>> to do today.)
>>
> yes, good idea...have fun with your project
>
>
>> Regards,
>> Dave
>>
>>> --
>>> ------------------------------------------------------------------------
>>> MzK
>>>
>>> "Those who love deeply never grow old;
>>> they may die of old age, but they die young."
>>> -- Sir Arthur Pinero
>>
>
Re: [www] html instead of markdown (mdtext)?
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Aug 11, 2011 at 10:13 AM, Dave Fisher <da...@comcast.net> wrote:
>
> On Aug 11, 2011, at 9:12 AM, Kay Schenk wrote:
>
> > I am proposing that we adopt plain HTML for the OOo website instead of
> the current markdown (mdtext) implementation.
>
> We can mix and match.
>
yes, but... mdtext is converted to html anyway. I just think the overhead --
i.e. maintenance by existing and "new" folks -- will be unweildy.
>
> >
> > I hesitate to make this recommendation given ALL the time and research
> Dave and others have already spent on the current incubator website, but, I
> feel, given that we will be migrating a rather large existing site, it makes
> sense.
>
> Don't worry about me. What I've learned is useful to me even if we decide
> to take another approach.
>
> How do you propose handling all of the Kenai wrapping?
uh...I'll be honest...I am not familiar with the " Kenai wrapping". And I
dare say, probably few are. My *guess* is this in invovled in
headers,footers, and ????
We might be able to ignore whatever this is and just get on with something
WAY simpler for the time being.
The new site won't be registering users and probably doesn't need a lot of
> the current *.vm and *.html.html files.
>
> >
> > I also realize that doing this will "break" the ability to use the webgui
> editing capability of the Apache CMS, forcing everyone to use svn for page
> updates. However, I don't have a good feel right now for the ultimate impact
> of that -- e.g. what do we expect in terms of web site editors.
>
> You really CAN edit HTML using the Apache CMS Web-Gui. It is just that I
> currently like unwrapped body html.
>
Oh--OK -- I hadn't tried this and this isn't what the web page about the CMS
indicates.
So, even better.
>
>
> > This would allow us to continue to use the default template system
> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
> text with normal HTML. HTML files shouldn't require any "wrapping" functions
> at all I think, since this is the indigenous format for web servers. We
> would have to bypass header, footer and navigation items for anything that
> *isn't* html, like js, css files.
>
> In the back of my head this week I've been thinking about a way to use
> properly formed html and then "rewrap" to apply consistent headers and
> footers is forming. The idea is to use an xslt filter to extract html from
> the <head> and <body>.
>
Well this may be super but unfortunately I am not knowledgable enough to
really know what you're saying here. But isn't this the purpose of the
template system -- to just patch on the headers, footers, anythng else?
Again, I am thinking "project long-term". I think it's vital to put
something in place that the regular web-jockey is familiar with.
> For the head - grab various elements including scripts and style. For the
> body grab it all. There are at least two advantages:
>
> (1) Each html page can be separated and tested outside of site framework.
> (2) Every html page published on the site automatically has the proper
> framework.
>
> >
> > Unfortunately, I've had a very difficult time this week trying to find
> any information on the setup details of Dotiac::DTL (documentation not
> available) -- the relationship of the two .pm files to the template areas,
> etc.
>
> It took me sometime to understand how it works. If you follow the
> instructions on running locally - website-local.mdtext - it ought to work.
>
OK--I still have NOT done that. The thing is the instructions still do NOT
give details on the setup of Dotiac::DTL. If I installed that locally, maybe
some documentation would emerge. And I will do that. There's LOADS of info
on django -- but not this perl wrapper.
> Perhaps we should IRC tomorrow and we can identify the disconnect in this
> documentation.
>
uh--sorry, I'm unavailable tomorrow. I think YOUR documentation is fine
really for what you're trying to get people to do -- with dealing with
mdtext. But, this is kind of my point.
*IF* we went straight html, and *IF* the templates were setup and fixed in
place -- yes, we'd need a perl/django wonk for this aspect (along with some
MUCH better documentation on this aspect) -- folks wouldn't have to do a
local setup at all. They'd simply edit HTML and commit the way we've always
done in the past. Much simpler in my mind.
>
> > I took at look around at many the Apache web areas (svn) at:
> >
> > http://svn.apache.org/repos/asf/
> >
> > You will see, as I did, that the vast majority are not using markdown,
> and this is NOT a requirement.
>
> It is not a requirement, it was a recommendation. (POI uses a very old
> version of Forrest and no one has wanted to change...)
>
> >
> > Anyway, thoughts/comments on this proposal?
>
> Let's see if others have something to say. (I've got some Fortran and SQL
> to do today.)
>
yes, good idea...have fun with your project
>
> Regards,
> Dave
>
> > --
> > ------------------------------------------------------------------------
> > MzK
> >
> > "Those who love deeply never grow old;
> > they may die of old age, but they die young."
> > -- Sir Arthur Pinero
>
>
--
---------------------------------------------------------------------------------------
MzK
"Those who love deeply never grow old;
they may die of old age, but they die young."
-- Sir Arthur Pinero
Re: [www] html instead of markdown (mdtext)?
Posted by Dave Fisher <da...@comcast.net>.
On Aug 11, 2011, at 9:12 AM, Kay Schenk wrote:
> I am proposing that we adopt plain HTML for the OOo website instead of the current markdown (mdtext) implementation.
We can mix and match.
>
> I hesitate to make this recommendation given ALL the time and research Dave and others have already spent on the current incubator website, but, I feel, given that we will be migrating a rather large existing site, it makes sense.
Don't worry about me. What I've learned is useful to me even if we decide to take another approach.
How do you propose handling all of the Kenai wrapping? The new site won't be registering users and probably doesn't need a lot of the current *.vm and *.html.html files.
>
> I also realize that doing this will "break" the ability to use the webgui editing capability of the Apache CMS, forcing everyone to use svn for page updates. However, I don't have a good feel right now for the ultimate impact of that -- e.g. what do we expect in terms of web site editors.
You really CAN edit HTML using the Apache CMS Web-Gui. It is just that I currently like unwrapped body html.
> This would allow us to continue to use the default template system (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown text with normal HTML. HTML files shouldn't require any "wrapping" functions at all I think, since this is the indigenous format for web servers. We would have to bypass header, footer and navigation items for anything that *isn't* html, like js, css files.
In the back of my head this week I've been thinking about a way to use properly formed html and then "rewrap" to apply consistent headers and footers is forming. The idea is to use an xslt filter to extract html from the <head> and <body>.
For the head - grab various elements including scripts and style. For the body grab it all. There are at least two advantages:
(1) Each html page can be separated and tested outside of site framework.
(2) Every html page published on the site automatically has the proper framework.
>
> Unfortunately, I've had a very difficult time this week trying to find any information on the setup details of Dotiac::DTL (documentation not available) -- the relationship of the two .pm files to the template areas, etc.
It took me sometime to understand how it works. If you follow the instructions on running locally - website-local.mdtext - it ought to work.
Perhaps we should IRC tomorrow and we can identify the disconnect in this documentation.
> I took at look around at many the Apache web areas (svn) at:
>
> http://svn.apache.org/repos/asf/
>
> You will see, as I did, that the vast majority are not using markdown, and this is NOT a requirement.
It is not a requirement, it was a recommendation. (POI uses a very old version of Forrest and no one has wanted to change...)
>
> Anyway, thoughts/comments on this proposal?
Let's see if others have something to say. (I've got some Fortran and SQL to do today.)
Regards,
Dave
> --
> ------------------------------------------------------------------------
> MzK
>
> "Those who love deeply never grow old;
> they may die of old age, but they die young."
> -- Sir Arthur Pinero
Re: [www] html instead of markdown (mdtext)?
Posted by Dave Fisher <da...@comcast.net>.
Hi Kay,
On Aug 11, 2011, at 2:38 PM, Kay Schenk wrote:
> On Thu, Aug 11, 2011 at 12:44 PM, Rob Weir <ap...@robweir.com> wrote:
>
>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk <ka...@gmail.com> wrote:
>>> I am proposing that we adopt plain HTML for the OOo website instead of
>> the
>>> current markdown (mdtext) implementation.
>>>
>>> I hesitate to make this recommendation given ALL the time and research
>> Dave
>>> and others have already spent on the current incubator website, but, I
>> feel,
>>> given that we will be migrating a rather large existing site, it makes
>>> sense.
>>>
>>
>> Where can I find the sources for the current website? Not the wiki
>> stuff, but the parts that you think would be difficult to migrate?
>>
>
> Oh boy...all over the place! Each OO.o project has its own svn repository
> with this stuff!
> What I was trying to say, given my paltry knowledge, was that it would be
> impossible to convert the whole OO.o site to markdown. This was my point.
That is now quite clear. I definitely want to preserve the html although it will be transformed.
>
> However, I am now reading about the Apache CMS more carefully, and see
> this...
>
> "The build system relies on lib/path.pm to provide a specially formatted
> @patterns array to give the build system hints on which *view* to run for a
> given source file. The patterns are checked in order, and if none of the
> patterns match, the source file will simply be copied over to the build
> tree."
The key part. The template subroutine is picked here.
>
> This tells me if we did not specify ANY patterns, that everything would be
> copied to the *actual* Apache web site as is, which would be fine! However,
> we do need template processing.
Exactly ...
>
>
>>> I also realize that doing this will "break" the ability to use the webgui
>>> editing capability of the Apache CMS, forcing everyone to use svn for
>> page
>>> updates. However, I don't have a good feel right now for the ultimate
>> impact
>>> of that -- e.g. what do we expect in terms of web site editors.
>>>
>>> This would allow us to continue to use the default template system
>>> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
>>> text with normal HTML. HTML files shouldn't require any "wrapping"
>> functions
>>> at all I think, since this is the indigenous format for web servers. We
>>> would have to bypass header, footer and navigation items for anything
>> that
>>> *isn't* html, like js, css files.
>>>
>>
>> We should also consider that the best approach might be to not do
>> mdtext and not do Dotiac::DTL, but to adopt a newer framework.
>>
>
> heh...yeah, I thought of that, but since any new "framework", i.e. template
> system, must work with perl this would necessitate a module install by the
> Apache infra folks. Really, I am trying to suggest the "path of least
> resistance". We can work with the default framework for now as long as we
> don't get too crazy.
If you want to look at what is possible then use the bookmarklet to look into www.apache.org. This page is published hourly and the top three projects are shuffled while twitter and jira and other feeds are picked off. WIthout a huge amount of work we could do something similar for openoffice.org.
>>> Unfortunately, I've had a very difficult time this week trying to find
>> any
>>> information on the setup details of Dotiac::DTL (documentation not
>>> available) -- the relationship of the two .pm files to the template
>> areas,
>>> etc.
>>>
>>> I took at look around at many the Apache web areas (svn) at:
>>>
>>> http://svn.apache.org/repos/asf/
>>>
>>> You will see, as I did, that the vast majority are not using markdown,
>> and
>>> this is NOT a requirement.
>>>
>>> Anyway, thoughts/comments on this proposal?
>>
>> HTML is not a panacea, of course. It is very easy to design pages
>> that look bad, are broken from portability, internationalization and
>> accessibility standpoint, introduce security issues, etc. So having a
>> constrained markup can be a good thing for a web site that you expect
>> many people of various skill levels to edit.
>>
>
> OK, I know this but I also know anyone who does ANY web development deals
> with an IDE that at its heart deals with HTML. And, really I don't envision
> everyone even wanting to edit the web site ever! The good thing is 1) we can
> always setup test areas, and 2) we have a versioning system! In my 10 yrs of
> dealing with the current OO.o site, I know of no circumstance in which we've
> had an unrecoverable meltdown.
>
> However, because of what you've told me about Apache and committer's rights
> to projects, things WILL BE different here. Folks will not be quarantined to
> various areas. I don't know how much of a concern/factor that is to anyone.
Subscribe to ooo-commits@i.a.o and say something if you see a bad commit.
>
>
>> Just a thought: Could you do the entire website in MediaWiki, with
>> only exception cases (download page, etc.) done in HTML?
>>
>
> Yes, you could but again...there's the (maybe) conversion problem...HTML ->
> mediawiki.
>
> Let me do this. I'll try to get a realistic idea over the next few days of
> what I'll call "critical pages" -- those that should really *be* HTML, and
> we'll see what we've got, and what's left.
This would be good. I'll be investigating the generic transformation for the html.
>
> A final note that Dave brought up about kenai *.html and the *.vm files.
>
> I'm pretty sure the *.vm files were the old Collabnet architecture stuff,
> and can be ignored. Kenai html I haven't a clue about. I suspect they
> control headers, footers and other aspects, like user logins, individual
> project templates which we wouldn't be concerning ourselves with right now
> -- or shouldn't anyway.
Good then we'll check them in to preserve them and then remove them when convenient.
>
> We need to establish a reasonable goal for our end users. Give them
> something that looks familiar without a lot of the bells and whistles that
> no longer pertain.
+1.
Regards,
Dave
>
>
>
>>> --
>>> ------------------------------------------------------------------------
>>> MzK
>>>
>>> "Those who love deeply never grow old;
>>> they may die of old age, but they die young."
>>> -- Sir Arthur Pinero
>>>
>>
>
>
>
> --
> ---------------------------------------------------------------------------------------
> MzK
>
> "Those who love deeply never grow old;
> they may die of old age, but they die young."
> -- Sir Arthur Pinero
Re: [www] html instead of markdown (mdtext)?
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Aug 11, 2011 at 12:44 PM, Rob Weir <ap...@robweir.com> wrote:
> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk <ka...@gmail.com> wrote:
> > I am proposing that we adopt plain HTML for the OOo website instead of
> the
> > current markdown (mdtext) implementation.
> >
> > I hesitate to make this recommendation given ALL the time and research
> Dave
> > and others have already spent on the current incubator website, but, I
> feel,
> > given that we will be migrating a rather large existing site, it makes
> > sense.
> >
>
> Where can I find the sources for the current website? Not the wiki
> stuff, but the parts that you think would be difficult to migrate?
>
Oh boy...all over the place! Each OO.o project has its own svn repository
with this stuff!
What I was trying to say, given my paltry knowledge, was that it would be
impossible to convert the whole OO.o site to markdown. This was my point.
However, I am now reading about the Apache CMS more carefully, and see
this...
"The build system relies on lib/path.pm to provide a specially formatted
@patterns array to give the build system hints on which *view* to run for a
given source file. The patterns are checked in order, and if none of the
patterns match, the source file will simply be copied over to the build
tree."
This tells me if we did not specify ANY patterns, that everything would be
copied to the *actual* Apache web site as is, which would be fine! However,
we do need template processing.
> > I also realize that doing this will "break" the ability to use the webgui
> > editing capability of the Apache CMS, forcing everyone to use svn for
> page
> > updates. However, I don't have a good feel right now for the ultimate
> impact
> > of that -- e.g. what do we expect in terms of web site editors.
> >
> > This would allow us to continue to use the default template system
> > (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
> > text with normal HTML. HTML files shouldn't require any "wrapping"
> functions
> > at all I think, since this is the indigenous format for web servers. We
> > would have to bypass header, footer and navigation items for anything
> that
> > *isn't* html, like js, css files.
> >
>
> We should also consider that the best approach might be to not do
> mdtext and not do Dotiac::DTL, but to adopt a newer framework.
>
heh...yeah, I thought of that, but since any new "framework", i.e. template
system, must work with perl this would necessitate a module install by the
Apache infra folks. Really, I am trying to suggest the "path of least
resistance". We can work with the default framework for now as long as we
don't get too crazy.
> > Unfortunately, I've had a very difficult time this week trying to find
> any
> > information on the setup details of Dotiac::DTL (documentation not
> > available) -- the relationship of the two .pm files to the template
> areas,
> > etc.
> >
> > I took at look around at many the Apache web areas (svn) at:
> >
> > http://svn.apache.org/repos/asf/
> >
> > You will see, as I did, that the vast majority are not using markdown,
> and
> > this is NOT a requirement.
> >
> > Anyway, thoughts/comments on this proposal?
>
> HTML is not a panacea, of course. It is very easy to design pages
> that look bad, are broken from portability, internationalization and
> accessibility standpoint, introduce security issues, etc. So having a
> constrained markup can be a good thing for a web site that you expect
> many people of various skill levels to edit.
>
OK, I know this but I also know anyone who does ANY web development deals
with an IDE that at its heart deals with HTML. And, really I don't envision
everyone even wanting to edit the web site ever! The good thing is 1) we can
always setup test areas, and 2) we have a versioning system! In my 10 yrs of
dealing with the current OO.o site, I know of no circumstance in which we've
had an unrecoverable meltdown.
However, because of what you've told me about Apache and committer's rights
to projects, things WILL BE different here. Folks will not be quarantined to
various areas. I don't know how much of a concern/factor that is to anyone.
> Just a thought: Could you do the entire website in MediaWiki, with
> only exception cases (download page, etc.) done in HTML?
>
Yes, you could but again...there's the (maybe) conversion problem...HTML ->
mediawiki.
Let me do this. I'll try to get a realistic idea over the next few days of
what I'll call "critical pages" -- those that should really *be* HTML, and
we'll see what we've got, and what's left.
A final note that Dave brought up about kenai *.html and the *.vm files.
I'm pretty sure the *.vm files were the old Collabnet architecture stuff,
and can be ignored. Kenai html I haven't a clue about. I suspect they
control headers, footers and other aspects, like user logins, individual
project templates which we wouldn't be concerning ourselves with right now
-- or shouldn't anyway.
We need to establish a reasonable goal for our end users. Give them
something that looks familiar without a lot of the bells and whistles that
no longer pertain.
> > --
> > ------------------------------------------------------------------------
> > MzK
> >
> > "Those who love deeply never grow old;
> > they may die of old age, but they die young."
> > -- Sir Arthur Pinero
> >
>
--
---------------------------------------------------------------------------------------
MzK
"Those who love deeply never grow old;
they may die of old age, but they die young."
-- Sir Arthur Pinero
Re: [www] html instead of markdown (mdtext)?
Posted by Dave Fisher <da...@comcast.net>.
On Aug 12, 2011, at 8:15 AM, Rob Weir wrote:
> On Fri, Aug 12, 2011 at 10:10 AM, Shane Curcuru <as...@shanecurcuru.org> 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<ga...@16degrees.com.au>
>>> wrote:
>>
>>>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<ka...@gmail.com>
>>
>> ...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 apache.org 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
> openoffice.apache.org or the current www.openoffice.org. 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 openoffice.org is considered to be "main".
>
> 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 https://cwiki.apache.org/ 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 www.apache.org/index.html is made "dynamic".
Regards,
Dave
Re: [www] html instead of markdown (mdtext)?
Posted by Rob Weir <ap...@robweir.com>.
On Fri, Aug 12, 2011 at 12:19 PM, Terry Ellison <Te...@ellisons.org.uk> wrote:
> Rob,
>
> I support your general point. Using static HTML files to achieve might have
> been a sound argument in the 1990s, but it isn't really credible with today
> platform technologies. What are the transactional rates for the Apache
> site? How many requests per second even just roughly?
>
> Taking your example of the MediaWiki engine, this is scaled to meet the
> transactional and data volume demand of wikipedia.org, one of the busiest
> websites on the planet. (There are typically ~100 updates per second and
> goodness know how many pageviews.) See http://www.mediawiki.org/wiki/Cache
> and the few dozen subsidiary pages. There are many high performance caching
> products that address this issue -- Apache even does one:
> http://trafficserver.apache.org/ -- and the mediaWiki engine already
> integrates with a couple of the leaders: Squid and Varnish.
>
> Apache's "heartland" is its "number one HTTP server on the Internet". Are
> we rally saying that the best way to manage content is through static HTML
> files? This is just daft IHMO. Has anyone ever heard of current CMS
> technology.
>
If you read the thread, it started by a suggestion from me that we use
the wiki as the main website. Than Gavin said the main website must
be served (not necessarily managed) as static HTML. I asked why.
Shane said it was for performance reasons. I said that caching should
be able to handle that.
So I don't think you and I disagree on this point. If you think you
do, then you'll need to try harder to explain it. I certainly am not
disagreeing with you. Unless I misunderstood you ;-)
> How many content editors and contributors can read HTML these days?
>
> One other point: yes SVN or any equivalent versioning repository can store
> most types of content, but versioning should take place at the highest level
> of abstraction and language that the content providers work in. Take an
> extreme example to emphasise this point. svn can store object modules, but
> does this mean that we should use these are the master control and
> disassemble back to assembly code to update programs. Of course not. But
> to many editors, HTML is little more that binary machine code.
>
> Non-functional (infrastructure) requirements help drive the design and
> implementation cycles but they shouldn't unnecessarily limit the true
> functional requirements of the system. To do so is madness. Is is really
> an approach Apache wants to advocate?
>
> Regards
> Terry
>>
>> On Fri, Aug 12, 2011 at 10:10 AM, Shane Curcuru<as...@shanecurcuru.org>
>> 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<ga...@16degrees.com.au>
>>>> wrote:
>>>>>>
>>>>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<ka...@gmail.com>
>>>
>>> ...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 apache.org 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
>> openoffice.apache.org or the current www.openoffice.org. 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.
>>
>> 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.
>>
>> 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.
>>
>>
>>> 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.
>>>
>>> - Shane
>>>
>
>
The impact of the OOo community sties on Apache.org domain volumetrics
Posted by Terry Ellison <te...@apache.org>.
Shane,
Thanks for these very useful volumetric links. I have a Q about Henk's
stats. I see that the total requests / month across all apache sites
run at ~350M requests. Is this Apache requests (e.g. an aggregate
linecount of all Apache access logs) or just the main document requests
(e.g. ignoring furniture such as CSS, JS and images used to render pages).
It's just that the OOo community wiki and forums combined run at over 2M
requests per day. That is when these two VMs go online, this could
represent and overall monthly increase in requests to apache.org of
60-70M; that's an increase of some 20% on the 350M baseline. (This is
just the two community services, and not counting the rest of the OOo
sites or download requests.)
Just something that we should consider.
Regards
Terry
<Was Re: [www] html instead of markdown (mdtext)?>
On 12/08/11 17:50, Shane Curcuru wrote:
> <snip>
> Information about Apache infrastructure is available:
>
> https://www.apache.org/dev/machines.html
> https://people.apache.org/~henkp/ (lots of links)
> https://people.apache.org/~vgritsenko/stats/daily.html
> https://www.apache.org/mirrors/
Re: [www] html instead of markdown (mdtext)?
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Hey, my only role with Apache infrastructure is as court jester, so I'm
not the one to help here: folks will need to organize specific proposals
and work with the Apache infra team.
Note this is *not* about which is the fastest way to serve content. The
real question is how the Apache infra team - working within a non-profit
org, with limited physical and admin resources - can effectively and
reliably manage all services our many projects ask for.
Information about Apache infrastructure is available:
https://www.apache.org/dev/machines.html
https://people.apache.org/~henkp/ (lots of links)
https://people.apache.org/~vgritsenko/stats/daily.html
https://www.apache.org/mirrors/
- Shane
P.S. the CMS by default stores both the mdtext and the final html output
both in SVN.
The mdtext is in your working SVN area, with diffs to the appropriate
project lists, so that the team can see what changes are being made in
terms of the content people develop.
The final html is in the staging/production website SVN areas, mainly
for backup recovery and security. If the server's lost, just install
httpd somewhere, and then svn checkout the html tree.
On 8/12/2011 12:19 PM, Terry Ellison wrote:
> Rob,
>
> I support your general point. Using static HTML files to achieve might
> have been a sound argument in the 1990s, but it isn't really credible
> with today platform technologies. What are the transactional rates for
> the Apache site? How many requests per second even just roughly?
>
> Taking your example of the MediaWiki engine, this is scaled to meet the
> transactional and data volume demand of wikipedia.org, one of the
> busiest websites on the planet. (There are typically ~100 updates per
> second and goodness know how many pageviews.) See
> http://www.mediawiki.org/wiki/Cache and the few dozen subsidiary pages.
> There are many high performance caching products that address this issue
> -- Apache even does one: http://trafficserver.apache.org/ -- and the
> mediaWiki engine already integrates with a couple of the leaders: Squid
> and Varnish.
>
> Apache's "heartland" is its "number one HTTP server on the Internet".
> Are we rally saying that the best way to manage content is through
> static HTML files? This is just daft IHMO. Has anyone ever heard of
> current CMS technology.
>
> How many content editors and contributors can read HTML these days?
>
> One other point: yes SVN or any equivalent versioning repository can
> store most types of content, but versioning should take place at the
> highest level of abstraction and language that the content providers
> work in. Take an extreme example to emphasise this point. svn can store
> object modules, but does this mean that we should use these are the
> master control and disassemble back to assembly code to update programs.
> Of course not. But to many editors, HTML is little more that binary
> machine code.
>
> Non-functional (infrastructure) requirements help drive the design and
> implementation cycles but they shouldn't unnecessarily limit the true
> functional requirements of the system. To do so is madness. Is is really
> an approach Apache wants to advocate?
>
> Regards
> Terry
>> On Fri, Aug 12, 2011 at 10:10 AM, Shane Curcuru<as...@shanecurcuru.org>
>> 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<ga...@16degrees.com.au>
>>>> wrote:
>>>>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<ka...@gmail.com>
>>> ...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 apache.org 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
>> openoffice.apache.org or the current www.openoffice.org. 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.
>>
>> 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.
>>
>> 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.
>>
>>
>>> 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.
>>>
>>> - Shane
>>>
>
Re: [www] html instead of markdown (mdtext)?
Posted by Terry Ellison <Te...@ellisons.org.uk>.
Rob,
I support your general point. Using static HTML files to achieve might
have been a sound argument in the 1990s, but it isn't really credible
with today platform technologies. What are the transactional rates for
the Apache site? How many requests per second even just roughly?
Taking your example of the MediaWiki engine, this is scaled to meet the
transactional and data volume demand of wikipedia.org, one of the
busiest websites on the planet. (There are typically ~100 updates per
second and goodness know how many pageviews.) See
http://www.mediawiki.org/wiki/Cache and the few dozen subsidiary pages.
There are many high performance caching products that address this issue
-- Apache even does one: http://trafficserver.apache.org/ -- and the
mediaWiki engine already integrates with a couple of the leaders: Squid
and Varnish.
Apache's "heartland" is its "number one HTTP server on the Internet".
Are we rally saying that the best way to manage content is through
static HTML files? This is just daft IHMO. Has anyone ever heard of
current CMS technology.
How many content editors and contributors can read HTML these days?
One other point: yes SVN or any equivalent versioning repository can
store most types of content, but versioning should take place at the
highest level of abstraction and language that the content providers
work in. Take an extreme example to emphasise this point. svn can
store object modules, but does this mean that we should use these are
the master control and disassemble back to assembly code to update
programs. Of course not. But to many editors, HTML is little more that
binary machine code.
Non-functional (infrastructure) requirements help drive the design and
implementation cycles but they shouldn't unnecessarily limit the true
functional requirements of the system. To do so is madness. Is is
really an approach Apache wants to advocate?
Regards
Terry
> On Fri, Aug 12, 2011 at 10:10 AM, Shane Curcuru<as...@shanecurcuru.org> 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<ga...@16degrees.com.au>
>>> wrote:
>>>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<ka...@gmail.com>
>> ...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 apache.org 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
> openoffice.apache.org or the current www.openoffice.org. 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.
>
> 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.
>
> 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.
>
>
>> 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.
>>
>> - Shane
>>
Re: [www] html instead of markdown (mdtext)?
Posted by Rob Weir <ap...@robweir.com>.
On Fri, Aug 12, 2011 at 10:10 AM, Shane Curcuru <as...@shanecurcuru.org> 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<ga...@16degrees.com.au>
>> wrote:
>
>>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<ka...@gmail.com>
>
> ...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 apache.org 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
openoffice.apache.org or the current www.openoffice.org. 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.
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.
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.
> 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.
>
> - Shane
>
Re: [www] html instead of markdown (mdtext)?
Posted by Shane Curcuru <as...@shanecurcuru.org>.
(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<ga...@16degrees.com.au> wrote:
>>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk<ka...@gmail.com>
...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 apache.org 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.
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.
- Shane
Re: [www] html instead of markdown (mdtext)?
Posted by Rob Weir <ap...@robweir.com>.
On Fri, Aug 12, 2011 at 3:41 AM, Gavin McDonald <ga...@16degrees.com.au> wrote:
>
>
>> -----Original Message-----
>> From: Rob Weir [mailto:apache@robweir.com]
>> Sent: Friday, 12 August 2011 5:45 AM
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: [www] html instead of markdown (mdtext)?
>>
>> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk <ka...@gmail.com>
>> wrote:
>> > I am proposing that we adopt plain HTML for the OOo website instead of
>> > the current markdown (mdtext) implementation.
>> >
>> > I hesitate to make this recommendation given ALL the time and research
>> > Dave and others have already spent on the current incubator website,
>> > but, I feel, given that we will be migrating a rather large existing
>> > site, it makes sense.
>> >
>>
>> Where can I find the sources for the current website? Not the wiki stuff, but
>> the parts that you think would be difficult to migrate?
>>
>> > I also realize that doing this will "break" the ability to use the
>> > webgui editing capability of the Apache CMS, forcing everyone to use
>> > svn for page updates. However, I don't have a good feel right now for
>> > the ultimate impact of that -- e.g. what do we expect in terms of web site
>> editors.
>> >
>> > This would allow us to continue to use the default template system
>> > (Dotiac::DTL) but eliminate the need for wrapping or intermixing
>> > markdown text with normal HTML. HTML files shouldn't require any
>> > "wrapping" functions at all I think, since this is the indigenous
>> > format for web servers. We would have to bypass header, footer and
>> > navigation items for anything that
>> > *isn't* html, like js, css files.
>> >
>>
>> We should also consider that the best approach might be to not do mdtext
>> and not do Dotiac::DTL, but to adopt a newer framework.
>>
>> > Unfortunately, I've had a very difficult time this week trying to find
>> > any information on the setup details of Dotiac::DTL (documentation not
>> > available) -- the relationship of the two .pm files to the template
>> > areas, etc.
>> >
>> > I took at look around at many the Apache web areas (svn) at:
>> >
>> > http://svn.apache.org/repos/asf/
>> >
>> > You will see, as I did, that the vast majority are not using markdown,
>> > and this is NOT a requirement.
>> >
>> > Anyway, thoughts/comments on this proposal?
>>
>> HTML is not a panacea, of course. It is very easy to design pages that look
>> bad, are broken from portability, internationalization and accessibility
>> standpoint, introduce security issues, etc. So having a constrained markup
>> can be a good thing for a web site that you expect many people of various
>> skill levels to edit.
>>
>> 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.
> The website will
> be housed where we house all our websites, on the main www infra
> machines, with code kept in svn. How that code gets there can differ and
> there are a variety of publishing tools and CMS to do the job. The preferred
> CMS of course is the built in CMS - which is being used currently.
> Other methods can include putting html pages directly in svn and these can
> be hand written, produced with a build tool such as Maven or Apache Forrest
> or whatever.
>
> Continue discussing but please take the wiki out of the equation as being the
> main website. The wiki will be treated like the forums and like the bug tracker
> etc, as a resource.
>
> Gav...
>
>
>
RE: [www] html instead of markdown (mdtext)?
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Rob Weir [mailto:apache@robweir.com]
> Sent: Friday, 12 August 2011 5:45 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: [www] html instead of markdown (mdtext)?
>
> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk <ka...@gmail.com>
> wrote:
> > I am proposing that we adopt plain HTML for the OOo website instead of
> > the current markdown (mdtext) implementation.
> >
> > I hesitate to make this recommendation given ALL the time and research
> > Dave and others have already spent on the current incubator website,
> > but, I feel, given that we will be migrating a rather large existing
> > site, it makes sense.
> >
>
> Where can I find the sources for the current website? Not the wiki stuff, but
> the parts that you think would be difficult to migrate?
>
> > I also realize that doing this will "break" the ability to use the
> > webgui editing capability of the Apache CMS, forcing everyone to use
> > svn for page updates. However, I don't have a good feel right now for
> > the ultimate impact of that -- e.g. what do we expect in terms of web site
> editors.
> >
> > This would allow us to continue to use the default template system
> > (Dotiac::DTL) but eliminate the need for wrapping or intermixing
> > markdown text with normal HTML. HTML files shouldn't require any
> > "wrapping" functions at all I think, since this is the indigenous
> > format for web servers. We would have to bypass header, footer and
> > navigation items for anything that
> > *isn't* html, like js, css files.
> >
>
> We should also consider that the best approach might be to not do mdtext
> and not do Dotiac::DTL, but to adopt a newer framework.
>
> > Unfortunately, I've had a very difficult time this week trying to find
> > any information on the setup details of Dotiac::DTL (documentation not
> > available) -- the relationship of the two .pm files to the template
> > areas, etc.
> >
> > I took at look around at many the Apache web areas (svn) at:
> >
> > http://svn.apache.org/repos/asf/
> >
> > You will see, as I did, that the vast majority are not using markdown,
> > and this is NOT a requirement.
> >
> > Anyway, thoughts/comments on this proposal?
>
> HTML is not a panacea, of course. It is very easy to design pages that look
> bad, are broken from portability, internationalization and accessibility
> standpoint, introduce security issues, etc. So having a constrained markup
> can be a good thing for a web site that you expect many people of various
> skill levels to edit.
>
> 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.
The website will
be housed where we house all our websites, on the main www infra
machines, with code kept in svn. How that code gets there can differ and
there are a variety of publishing tools and CMS to do the job. The preferred
CMS of course is the built in CMS - which is being used currently.
Other methods can include putting html pages directly in svn and these can
be hand written, produced with a build tool such as Maven or Apache Forrest
or whatever.
Continue discussing but please take the wiki out of the equation as being the
main website. The wiki will be treated like the forums and like the bug tracker
etc, as a resource.
Gav...
Re: [www] html instead of markdown (mdtext)?
Posted by Dave Fisher <da...@comcast.net>.
On Aug 11, 2011, at 12:44 PM, Rob Weir wrote:
> On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk <ka...@gmail.com> wrote:
>> I am proposing that we adopt plain HTML for the OOo website instead of the
>> current markdown (mdtext) implementation.
>>
>> I hesitate to make this recommendation given ALL the time and research Dave
>> and others have already spent on the current incubator website, but, I feel,
>> given that we will be migrating a rather large existing site, it makes
>> sense.
>>
>
> Where can I find the sources for the current website? Not the wiki
> stuff, but the parts that you think would be difficult to migrate?
>
>> I also realize that doing this will "break" the ability to use the webgui
>> editing capability of the Apache CMS, forcing everyone to use svn for page
>> updates. However, I don't have a good feel right now for the ultimate impact
>> of that -- e.g. what do we expect in terms of web site editors.
>>
>> This would allow us to continue to use the default template system
>> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
>> text with normal HTML. HTML files shouldn't require any "wrapping" functions
>> at all I think, since this is the indigenous format for web servers. We
>> would have to bypass header, footer and navigation items for anything that
>> *isn't* html, like js, css files.
>>
>
> We should also consider that the best approach might be to not do
> mdtext and not do Dotiac::DTL, but to adopt a newer framework.
>
>> Unfortunately, I've had a very difficult time this week trying to find any
>> information on the setup details of Dotiac::DTL (documentation not
>> available) -- the relationship of the two .pm files to the template areas,
>> etc.
>>
>> I took at look around at many the Apache web areas (svn) at:
>>
>> http://svn.apache.org/repos/asf/
>>
>> You will see, as I did, that the vast majority are not using markdown, and
>> this is NOT a requirement.
>>
>> Anyway, thoughts/comments on this proposal?
>
> HTML is not a panacea, of course. It is very easy to design pages
> that look bad, are broken from portability, internationalization and
> accessibility standpoint, introduce security issues, etc. So having a
> constrained markup can be a good thing for a web site that you expect
> many people of various skill levels to edit.
>
> Just a thought: Could you do the entire website in MediaWiki, with
> only exception cases (download page, etc.) done in HTML?
We are looking for a solution that involves the least impact on the current content.
Of course we will need to review every page for IP and need to keep. I think we are two or three technical issues away from being able to script and apply consistent style and html framework around either mdtext and html.
Similar composition might work with other sites.
Regards,
Dave
>
>> --
>> ------------------------------------------------------------------------
>> MzK
>>
>> "Those who love deeply never grow old;
>> they may die of old age, but they die young."
>> -- Sir Arthur Pinero
>>
Re: [www] html instead of markdown (mdtext)?
Posted by Rob Weir <ap...@robweir.com>.
On Thu, Aug 11, 2011 at 12:12 PM, Kay Schenk <ka...@gmail.com> wrote:
> I am proposing that we adopt plain HTML for the OOo website instead of the
> current markdown (mdtext) implementation.
>
> I hesitate to make this recommendation given ALL the time and research Dave
> and others have already spent on the current incubator website, but, I feel,
> given that we will be migrating a rather large existing site, it makes
> sense.
>
Where can I find the sources for the current website? Not the wiki
stuff, but the parts that you think would be difficult to migrate?
> I also realize that doing this will "break" the ability to use the webgui
> editing capability of the Apache CMS, forcing everyone to use svn for page
> updates. However, I don't have a good feel right now for the ultimate impact
> of that -- e.g. what do we expect in terms of web site editors.
>
> This would allow us to continue to use the default template system
> (Dotiac::DTL) but eliminate the need for wrapping or intermixing markdown
> text with normal HTML. HTML files shouldn't require any "wrapping" functions
> at all I think, since this is the indigenous format for web servers. We
> would have to bypass header, footer and navigation items for anything that
> *isn't* html, like js, css files.
>
We should also consider that the best approach might be to not do
mdtext and not do Dotiac::DTL, but to adopt a newer framework.
> Unfortunately, I've had a very difficult time this week trying to find any
> information on the setup details of Dotiac::DTL (documentation not
> available) -- the relationship of the two .pm files to the template areas,
> etc.
>
> I took at look around at many the Apache web areas (svn) at:
>
> http://svn.apache.org/repos/asf/
>
> You will see, as I did, that the vast majority are not using markdown, and
> this is NOT a requirement.
>
> Anyway, thoughts/comments on this proposal?
HTML is not a panacea, of course. It is very easy to design pages
that look bad, are broken from portability, internationalization and
accessibility standpoint, introduce security issues, etc. So having a
constrained markup can be a good thing for a web site that you expect
many people of various skill levels to edit.
Just a thought: Could you do the entire website in MediaWiki, with
only exception cases (download page, etc.) done in HTML?
> --
> ------------------------------------------------------------------------
> MzK
>
> "Those who love deeply never grow old;
> they may die of old age, but they die young."
> -- Sir Arthur Pinero
>