1.) The time required to "process" a server-side include on a non-caching, shared-hosting server is negligible. I invite you to run some timed tests with lynx.
That depends on server-load, and you need things like xbithack to get proper caching with SSI anyway.
2.) The point behind using SSI is so that, every time the template is updated, only one file needs to be updated and uploaded.
The point behind using SSI is to reduce maintenance work. This happens at the expense of server resources. For small websites, the resources saved by not uploading all the files might outweigh the resources used by the server, but that doesn't hold true for all sites.
3.) Apache runs every HTML page through the interpreter regardless of whether it actually contains SSI code.
This isn't true unless you have deliberately changed the default settings to do this. The default configuration supplied by Apache doesn't even enable SSI by default - and when you uncomment the supplied code, it only applies to files ending in.shtml. Read the config file yourself.
Linux can and should be known as the web developer's platform
That isn't going to happen. Most people use Internet Explorer to surf the web. Internet Explorer contains crucial, website-destroying bugs. Professional web developers need to test in Internet Explorer. Things like WINE by their very nature cannot be used for testing purposes (found a bug? Is it a bug in Internet Explorer, or a bug in WINE?). Virtual machines like VMWare are the only practical solution for web developers who want to use Linux, and as far as I am aware, plex86 and bochs aren't ready for the end-user (and still require Windows!).
Can't you just block a handful of IPs at the firewall?
HTTP client IP addresses don't directly correspond to users. What happens when you block a proxy and hundreds of legitimate users can't get to your website?
Re:Here is what needs to be done
on
CSS for the LDP?
·
· Score: 1
Additionally, font tags, etc always take precidence over style sheets.
With all the process forking going on at heavily used sites, C would offer an immediate benefit.
The usual method of running PHP is with Apache configured to spawn a number of child processes when it starts up, and to handle connections using those processes.
A new process is not spawned for each new request. You may be thinking of the old standalone CGI method.
Since its inception, PHP has gone from a simple website templating language and form processing tool, to a semi-OO scripting language hacked onto a bunch of C extensions, and now they expect to become a fully OO, enterprise-ready language?
Scary.
Scary? Projects evolve. Apache wasn't always "enterprise ready". FreeBSD wasn't always "enterprise ready". Just because something started out as a pet project rather than at a lab, that doesn't mean it's automatically "tainted" and cannot ever be useful to big businesses.
Libraries of code written in a templating language!
PHP may have started out as a templating language, but it is a general purpose scripting language now. You can even write GUI applications with it.
And what is it with all those PHP developers who seem to think a "class" is another term for "static function library"? The concept of using object types is foreign to thse people - they'd rather make huge monster arrays.
So the language is judged on its worst practitioners? If that is the case, then, judging all languages equally, we'd better just give up this programming lark and hide under a rock.
Rewrites of crufty code are not exclusive to PHP, you know. Neither are bad developers.
Read what you wrote. Read what I wrote. You have veered off on a tangent. You said that presentation is content. I disagreed.
If that were true then of course dark gray on black would be just as effective as say black on white.
At no point did I say that all forms of presentation are equally effective. I do not believe that they are. How did you arrive at that conclusion from me stating that presentation isn't content?
Just because you trivialize presentation
I did not trivialize presentation. I'm merely pointing out that it isn't content.
Your English comprehension skills leave a lot to be desired.
Re:Gentoo docs are a good example
on
CSS for the LDP?
·
· Score: 1
CSS is designed to be backwards-compatible, so browsers that don't understand CSS still read the HTML. Of course, this assumes you have decent HTML to begin with.
The only real trouble you have in this respect is with Netscape 4.x and similarly broken browsers that attempt to use CSS, but fail miserably. The usual method of dealing with them is to "hide" the CSS from them using @import (which they don't understand). Google for "CSS filters" or "CSS hiding" for more details. Having said that, the sort of styling likely to be used for HOWTOs is that simple that even Netscape 4.x could probably deal with it.
XHTML is theoretically slightly incompatible with HTML, however practically-speaking, if you follow Appendix C of the XHTML 1.0 specification, you will not have any problems.
The instructions on how to write a CDRW are the same whether they are written in red text, blue text, on a slight slant, have a background image, or whatever. The instructions are the content. In cases like art projects, the line can get blurry, but when talking about things like HOWTOs, it's very clear cut.
I'm not sure what "geeks" have to do with it. Any reasonably intelligent person can see that how content is presented to a user is a separate concept to the content itself.
Thats the whole point of separation of content and presentation, that you shouldn't have to worry about "rebuilding" or otherwise updating a presentation layer because you change the data.
No, that's not the point. With Cocoon, the output documents are still "rebuilt", it just happens at a different point in the authoring->reading journey. Given that the formats have to be generated upon update anyway, the need for something like Cocoon is mitigated.
That said, cocoon could also be used to rebuild static output using all of the desired formats, in one go, whenever the xml data is updated.
Well they already have a mechanism in place to do that, although last time I checked, I think it was an overnight cron job that pulled the documents out of CVS and generated the output formats.
It's been a while since I've checked it out, can Cocoon pull stuff out of CVS and build tarballs that contain all the HOWTOs at once?
Re:readable printable LDP - how shocking
on
CSS for the LDP?
·
· Score: 1
I agree that adjusting headings isn't an issue, I'm talking about the normal text/overall setting.
As for Mezzoblue, yes, it's poor usability. When a website can use the right font size automatically and chooses to set it to something else with the option of setting it back manually, yes, that's poor usability.
In terms of the actual mechanism used, the buttons are completely unintuitive - a capital 'A' does not indicate to me that it will increase the font size. Given the target audience, it's less of an issue, but if that mechanism was used on a mainstream site, it would go unused by virtually everyone, regardless of whether or not people would prefer a larger font size.
Re:readable printable LDP - how shocking
on
CSS for the LDP?
·
· Score: 1
Maybe you could read up on CSS a little?
I can assure you that I am very familiar with CSS. You just seem to have missed my point.
Right now, when you read a HOWTO in HTML format, it uses your font size. The font size you are in control of, that can be configured in your browser.
When authors start messing with the font size with CSS, say trying to set it to 10pt Verdana, they screw around with what people have chosen as their ideal font size. When reducing font size or setting it to an absolute value, an author may make documents unreadable for many people unless those people know enough to specifically override the author's CSS.
I am sugesting that LDP use a style sheet, better yet several style sheets so that each user sees what he wants to see.
Great, so instead of actually using what the user wants automatically, the site uses font sizes that the author wants and the user has to mess around with site-specific controls to fix it. That's poor usability and a regression from the current behaviour.
Re:readable printable LDP - how shocking
on
CSS for the LDP?
·
· Score: 1
CSS will make LDP more readable, for the moment I have to modify my browser windo to get the columns of text to the correct width. I also have to modify font size.
The current HOWTOs don't modify the font size at all. They use what you have configured in your browser to be the default font size. If you don't like that size, change the settings in your browser and you will get what you want across all websites that use your default font size.
Please don't suggest that the LDP should start messing with the font size for the normal text. Plenty of people are happy with the font size they have configured their browser to use, messing with it is just going to get on peoples nerves, and reducing it may make the documentation much less readable.
Using anything other than apache cocoon for this project is ridiculous.
Blanket statements like that are ridiculous. Did you ever consider, since the LDP documents are widely mirrored and included in Linux distributions, that relying on server-side smarts is not such a good idea?
Their content is already written in DocBook and available in multiple formats. What benefit does Cocoon bring that isn't already achieved with the existing framework? Why should the documents be rendered dynamically rather than every time they are updated?
Since you can also apply to CSS to XML documents, why not just do that instead.
Because arbitrary XML documents don't have defined semantics that are understood by WWW software. XHTML does. How is Google supposed to know that you are talking about headings when you use <my-special-heading> elements instead of <h1> elements?
Furthermore, it doesn't degrade gracefully - if the XML styling doesn't get applied, users are stuck with a very unfriendly tree view of the elements in the document, rather than an unstyled HTML document. You can get around this with server-side negotiation, but that would up the requirements for LDP mirrors substantially.
I guess the real advantage is that you can easily parse the XML and "port" the documentation to something else as well be it PostScript, PDF, or some other format that toggles your switch.
The LDP already do this. They author in DocBook and transform it into multiple formats right now.
Re:To be quite frank - give me .txt
on
CSS for the LDP?
·
· Score: 2, Informative
I'm sure there's an option to get all the howtos and documentation in good old ascii out there _somewhere_, by the gods the LDP has made those more difficult to find.
Come on. I went to the LDP website, and clicked on HOWTOs. I scrolled down, and there was the link to the plain text versions.
I wouldn't describe one click away from the homepage to be "difficult to find".
Re:Each page will have a different style sheet
on
CSS for the LDP?
·
· Score: 1
they introduce a dependence on directory structure.
No they don't. You can refer to stylesheets using URIs that are relative to the root of the website and with absolute URIs just the same as with images, Javascript files, and any other type of link.
Second, getting different people to use the same style sheet on an open source project is tough.
Perhaps. At the moment they all agree on the current presentation. Nothing's stopping incremental changes, like moving to serif/sans-serif, etc.
Third, unless everybody edits HTML with the same WYSIWYG editor, nobody will be able to use a WYSIWYG editor on the HTML.
This is a non-issue. Nobody edits the HTML at all. The LDP uses DocBook as its source format. And "WYSIWYG" is stupid on the web, since renderings can differ, will differ, and should differ in many cases.
(Has anyone written an open-source Dreamweaver replacement yet?)
The old Google used to do this too - the term was underlined and you could click on it when there was a matching entry in dictionary.com. Obviously it wasn't prominent enough, and so they explicitly noted the definition link in this new version.
But if the cornerstone of the p2p problem is that people are distributing content for free, how exactly are we going to change the laws so that there remains some notion of copyright so that it's still vaible to produce music/movies/games?
Return copyright to sane terms, like a decade or two. How many albums/films/games really need a copyright duration of over ten years to become profitable? How many people would choose to download and share legal ten-year-old works rather than break the law with more recent works?
Microsoft licensing the APIs is irrelvant to Samba -- all the samba work is based on specifications which were either released publicly or which were independently reverse-engineered.
Says who? The Samba developers? If Samba gets a few new features in the next few years, what's to stop Microsoft accusing them from looking at the stuff that needs royalties, or looking at the leaked source code?
Remember - Microsoft don't have to win in court to win overall - they just have to have enough of a case to tie the Samba guys up for years or bankrupt them with legal fees.
Netscape killed themselves by not adding anything significant to their browser for years after they first released Communicator. Communicator was better than IE3, but not IE4, and included a whole bunch of extra junk (like that incredibly bad WYSIWYG HTML editor)
Netscape added quite a bit of stuff to their Gold edition that they were making a profit on. Then Microsoft bought Mosaic to catch up, and by around Internet Explorer 3, had caught up enough to make the Gold edition nonprofitable to Netscape, that was the point when they bundled it with the normal edition.
that increased the download size for every update to ridiculous amounts for a dialup connection.
False. There was always the standalone Navigator bundle that didn't include the extra stuff.
I don't think that blaming them for the failures of companies like Netscape is fair.
Microsoft used the funds they gained from their monopoly in operating systems to buy Mosaic, develop Internet Explorer, and give it away freely, and as a result, the market for their competitor Netscape's flagship product (who was threatening to remove OS lock-in with web applications) disappeared. If that's not blatant abuse of monopoly power, I don't know what is.
Netscape tried to base an entire corporation on selling what is a basic internet utility that should be included with every OS, just like a text editor or FTP client.
Just because everyone is used to it coming with the operating system now, it doesn't mean that it is sensible or that it was usual at the time.
If you look back at Microsoft's history, you will see that they have had a history of identifying competitors, developing an alternative to their flagship product, and bundling it with the next version of Windows.
It happened with web browsers, drive compression, MP3 players, IP stacks, firewalls, and it is happening now with virus scanners and popup blockers.
Sure, sometimes it makes sense to include certain features with an operating system. But that doesn't mean that it's always a good idea, or that the way Microsoft goes about it is.
Take the FTP client example you gave. None of the companies that are a threat to Microsoft have an FTP client as their flagship product. The FTP client Microsoft provides is about as basic as you can get, it doesn't provide many useful features at all.
Now look at the web browser example. A threat to Microsoft was making money by selling web browsers, and so the original Mosaic, which was basically just a rendering engine with back forward and home buttons, ballooned into a 100MB+ monster application with multiple client-side scripting engines, newsfeeds (remember Microsoft's aborted attempt at "channels"?), plugin interfaces, etc, etc.
For example, I need to know if a particular user's browser can render X*ML. If their browser doesn't tell me what version it is, I can't code according to the new standards.
No, that's completely the wrong way of going about it, especially as various browsers are quite happy to spoof the user-agent header.
HTTP includes an Accept header that allows a browser to tell the server which content types it can handle. If you want to know if a browser can handle particular types of files, look at that header rather than the User-Agent header.
It isn't about fixing incompatibilies between browsers
RFC 2616 (the HTTP 1.1 specification) disagrees with you:
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations.
Slashdot Mirror
I wonder if they'll be using the NSA's Linux against the NSA?
Nowhere in the article does it say that the computers have to be on.
That depends on server-load, and you need things like xbithack to get proper caching with SSI anyway.
The point behind using SSI is to reduce maintenance work. This happens at the expense of server resources. For small websites, the resources saved by not uploading all the files might outweigh the resources used by the server, but that doesn't hold true for all sites.
This isn't true unless you have deliberately changed the default settings to do this. The default configuration supplied by Apache doesn't even enable SSI by default - and when you uncomment the supplied code, it only applies to files ending in .shtml. Read the config file yourself.
That isn't going to happen. Most people use Internet Explorer to surf the web. Internet Explorer contains crucial, website-destroying bugs. Professional web developers need to test in Internet Explorer. Things like WINE by their very nature cannot be used for testing purposes (found a bug? Is it a bug in Internet Explorer, or a bug in WINE?). Virtual machines like VMWare are the only practical solution for web developers who want to use Linux, and as far as I am aware, plex86 and bochs aren't ready for the end-user (and still require Windows!).
HTTP client IP addresses don't directly correspond to users. What happens when you block a proxy and hundreds of legitimate users can't get to your website?
No, non-CSS presentation hints have a specificity of zero, and so should never take precedence over stylesheets.
The usual method of running PHP is with Apache configured to spawn a number of child processes when it starts up, and to handle connections using those processes.
A new process is not spawned for each new request. You may be thinking of the old standalone CGI method.
Scary? Projects evolve. Apache wasn't always "enterprise ready". FreeBSD wasn't always "enterprise ready". Just because something started out as a pet project rather than at a lab, that doesn't mean it's automatically "tainted" and cannot ever be useful to big businesses.
PHP may have started out as a templating language, but it is a general purpose scripting language now. You can even write GUI applications with it.
So the language is judged on its worst practitioners? If that is the case, then, judging all languages equally, we'd better just give up this programming lark and hide under a rock.
Rewrites of crufty code are not exclusive to PHP, you know. Neither are bad developers.
Read what you wrote. Read what I wrote. You have veered off on a tangent. You said that presentation is content. I disagreed.
At no point did I say that all forms of presentation are equally effective. I do not believe that they are. How did you arrive at that conclusion from me stating that presentation isn't content?
I did not trivialize presentation. I'm merely pointing out that it isn't content.
Your English comprehension skills leave a lot to be desired.
CSS is designed to be backwards-compatible, so browsers that don't understand CSS still read the HTML. Of course, this assumes you have decent HTML to begin with.
The only real trouble you have in this respect is with Netscape 4.x and similarly broken browsers that attempt to use CSS, but fail miserably. The usual method of dealing with them is to "hide" the CSS from them using @import (which they don't understand). Google for "CSS filters" or "CSS hiding" for more details. Having said that, the sort of styling likely to be used for HOWTOs is that simple that even Netscape 4.x could probably deal with it.
XHTML is theoretically slightly incompatible with HTML, however practically-speaking, if you follow Appendix C of the XHTML 1.0 specification, you will not have any problems.
The instructions on how to write a CDRW are the same whether they are written in red text, blue text, on a slight slant, have a background image, or whatever. The instructions are the content. In cases like art projects, the line can get blurry, but when talking about things like HOWTOs, it's very clear cut.
I'm not sure what "geeks" have to do with it. Any reasonably intelligent person can see that how content is presented to a user is a separate concept to the content itself.
No, that's not the point. With Cocoon, the output documents are still "rebuilt", it just happens at a different point in the authoring->reading journey. Given that the formats have to be generated upon update anyway, the need for something like Cocoon is mitigated.
Well they already have a mechanism in place to do that, although last time I checked, I think it was an overnight cron job that pulled the documents out of CVS and generated the output formats.
It's been a while since I've checked it out, can Cocoon pull stuff out of CVS and build tarballs that contain all the HOWTOs at once?
I agree that adjusting headings isn't an issue, I'm talking about the normal text/overall setting.
As for Mezzoblue, yes, it's poor usability. When a website can use the right font size automatically and chooses to set it to something else with the option of setting it back manually, yes, that's poor usability.
In terms of the actual mechanism used, the buttons are completely unintuitive - a capital 'A' does not indicate to me that it will increase the font size. Given the target audience, it's less of an issue, but if that mechanism was used on a mainstream site, it would go unused by virtually everyone, regardless of whether or not people would prefer a larger font size.
I can assure you that I am very familiar with CSS. You just seem to have missed my point.
Right now, when you read a HOWTO in HTML format, it uses your font size. The font size you are in control of, that can be configured in your browser.
When authors start messing with the font size with CSS, say trying to set it to 10pt Verdana, they screw around with what people have chosen as their ideal font size. When reducing font size or setting it to an absolute value, an author may make documents unreadable for many people unless those people know enough to specifically override the author's CSS.
Great, so instead of actually using what the user wants automatically, the site uses font sizes that the author wants and the user has to mess around with site-specific controls to fix it. That's poor usability and a regression from the current behaviour.
The current HOWTOs don't modify the font size at all. They use what you have configured in your browser to be the default font size. If you don't like that size, change the settings in your browser and you will get what you want across all websites that use your default font size.
Please don't suggest that the LDP should start messing with the font size for the normal text. Plenty of people are happy with the font size they have configured their browser to use, messing with it is just going to get on peoples nerves, and reducing it may make the documentation much less readable.
Blanket statements like that are ridiculous. Did you ever consider, since the LDP documents are widely mirrored and included in Linux distributions, that relying on server-side smarts is not such a good idea?
Their content is already written in DocBook and available in multiple formats. What benefit does Cocoon bring that isn't already achieved with the existing framework? Why should the documents be rendered dynamically rather than every time they are updated?
Because arbitrary XML documents don't have defined semantics that are understood by WWW software. XHTML does. How is Google supposed to know that you are talking about headings when you use <my-special-heading> elements instead of <h1> elements?
Furthermore, it doesn't degrade gracefully - if the XML styling doesn't get applied, users are stuck with a very unfriendly tree view of the elements in the document, rather than an unstyled HTML document. You can get around this with server-side negotiation, but that would up the requirements for LDP mirrors substantially.
The LDP already do this. They author in DocBook and transform it into multiple formats right now.
Come on. I went to the LDP website, and clicked on HOWTOs. I scrolled down, and there was the link to the plain text versions.
I wouldn't describe one click away from the homepage to be "difficult to find".
No they don't. You can refer to stylesheets using URIs that are relative to the root of the website and with absolute URIs just the same as with images, Javascript files, and any other type of link.
Perhaps. At the moment they all agree on the current presentation. Nothing's stopping incremental changes, like moving to serif/sans-serif, etc.
This is a non-issue. Nobody edits the HTML at all. The LDP uses DocBook as its source format. And "WYSIWYG" is stupid on the web, since renderings can differ, will differ, and should differ in many cases.
Quanta has a Visual Page Layout mode.
The old Google used to do this too - the term was underlined and you could click on it when there was a matching entry in dictionary.com. Obviously it wasn't prominent enough, and so they explicitly noted the definition link in this new version.
What about Dizzy? You can't get much stranger than a wizard-fighting hard-boiled egg.
Return copyright to sane terms, like a decade or two. How many albums/films/games really need a copyright duration of over ten years to become profitable? How many people would choose to download and share legal ten-year-old works rather than break the law with more recent works?
Says who? The Samba developers? If Samba gets a few new features in the next few years, what's to stop Microsoft accusing them from looking at the stuff that needs royalties, or looking at the leaked source code?
Remember - Microsoft don't have to win in court to win overall - they just have to have enough of a case to tie the Samba guys up for years or bankrupt them with legal fees.
Netscape added quite a bit of stuff to their Gold edition that they were making a profit on. Then Microsoft bought Mosaic to catch up, and by around Internet Explorer 3, had caught up enough to make the Gold edition nonprofitable to Netscape, that was the point when they bundled it with the normal edition.
False. There was always the standalone Navigator bundle that didn't include the extra stuff.
Microsoft used the funds they gained from their monopoly in operating systems to buy Mosaic, develop Internet Explorer, and give it away freely, and as a result, the market for their competitor Netscape's flagship product (who was threatening to remove OS lock-in with web applications) disappeared. If that's not blatant abuse of monopoly power, I don't know what is.
Just because everyone is used to it coming with the operating system now, it doesn't mean that it is sensible or that it was usual at the time.
If you look back at Microsoft's history, you will see that they have had a history of identifying competitors, developing an alternative to their flagship product, and bundling it with the next version of Windows.
It happened with web browsers, drive compression, MP3 players, IP stacks, firewalls, and it is happening now with virus scanners and popup blockers.
Sure, sometimes it makes sense to include certain features with an operating system. But that doesn't mean that it's always a good idea, or that the way Microsoft goes about it is.
Take the FTP client example you gave. None of the companies that are a threat to Microsoft have an FTP client as their flagship product. The FTP client Microsoft provides is about as basic as you can get, it doesn't provide many useful features at all.
Now look at the web browser example. A threat to Microsoft was making money by selling web browsers, and so the original Mosaic, which was basically just a rendering engine with back forward and home buttons, ballooned into a 100MB+ monster application with multiple client-side scripting engines, newsfeeds (remember Microsoft's aborted attempt at "channels"?), plugin interfaces, etc, etc.
No, that's completely the wrong way of going about it, especially as various browsers are quite happy to spoof the user-agent header.
HTTP includes an Accept header that allows a browser to tell the server which content types it can handle. If you want to know if a browser can handle particular types of files, look at that header rather than the User-Agent header.
RFC 2616 (the HTTP 1.1 specification) disagrees with you: