Subdirectories/folders as URLs? (novice question)

[AES/newspost]

My understanding -- I'm not an expert -- is that on (some? many? all?)
standard Internet servers a URL can point to a subdirectory name
followed by a backslash, and that links to this URL will automatically
go to an "index.html" file located in that subdirectory, if there is one.

Q1: Is this more or less correct?

At least some HTML texts also recommend using this as the basis for
organizing a web site: Put the web pages associated with some specific
or isolated subtopic into an appropriately named subdirectory (or
subsubdirectory) within the main web site's top level directory; use an
index.html file located in that subdirectory to serve as the "home
page" for links to those subtopic pages within that subdirectory; and
use the subdirectory's name as the primary URL for linking to that
subtopic from outside or from higher up in the web site hierarchy.

Q2: Is this good advice?

But if I'm attempting to develop and test a complete web site on my own
(Mac iBook OS 9) computer before uploading it to my university's server,
I can't do this, because subdirectories are folders in this environment
and as best I can tell browsers operating on my own machine can't link
to folders as URLs.

Q3: If this is correct, is there any way around it? (at the Mac OS 9
level, or if I upgrade to Mac OS X)

Thanks for any advice or assistance.

[Dave Patton]

AES/newspost <si*****@stanford.edu> wrote in news:siegman-
A6*******************@news.stanford.edu:

My understanding -- I'm not an expert -- is that on (some? many? all?)
standard Internet servers a URL can point to a subdirectory name
followed by a backslash, and that links to this URL will automatically
go to an "index.html" file located in that subdirectory, if there is one.

Q1: Is this more or less correct?
"\" is a backslash, "/" is a slash or forwardslash. It's not clear
from your wording if you think backslashes can be used in URLs.

As for 'indexing a directory', here's how Apache handles it:
http://httpd.apache.org/docs/mod/mod...directoryindex
http://httpd.apache.org/docs/mod/mod_autoindex.html
At least some HTML texts also recommend using this as the basis for
organizing a web site: Put the web pages associated with some specific
or isolated subtopic into an appropriately named subdirectory (or
subsubdirectory) within the main web site's top level directory; use an
index.html file located in that subdirectory to serve as the "home
page" for links to those subtopic pages within that subdirectory;
So far, so good (maybe) ....
and use the subdirectory's name as the primary URL for linking to that
subtopic from outside or from higher up in the web site hierarchy.
That may not be good advice. You might want to read
"Cool URIs don't change" by Tim Berners-Lee:
http://www.w3.org/Provider/Style/URI
But if I'm attempting to develop and test a complete web site on my own
(Mac iBook OS 9) computer before uploading it to my university's server

You can't properly test on your own system anyway, because you
haven't duplicated the university's webserver environment. For
example, you might discover that thier webserver serves your
pages with HTTP headers that cause you problems.

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/

[Joel Shepherd]

In article <si***************************@news.stanford.edu >,
AES/newspost <si*****@stanford.edu> wrote:

My understanding -- I'm not an expert -- is that on (some? many? all?)
standard Internet servers a URL can point to a subdirectory name
followed by a backslash...
I believe you mean a solidus: i.e., a forward-slash. But anyway...
and that links to this URL will automatically go to an "index.html"
file located in that subdirectory, if there is one.

Q1: Is this more or less correct?
It is if the webserver is configured appropriately. If the URL is only a
path -- no document name appended -- the webserver can be configured to
try to return a default document (e.g., "index.html") for that path.
Often several default document names can be specified, in a prioritized
list.

At least some HTML texts also recommend using this as the basis for
organizing a web site:

Q2: Is this good advice?
Well, subdirectories are useful for organizing files, whether part of a
web site or something else.

Personally, w/regard to default documents, I'm a little on the fence as
to their usefulness. On one hand, it can make life easier for both the
visitor and author to not have to specify a full path (think,
especially, of the home page). The main risk of relying on the server's
default document configuration is that if the site is moved to a
different server with a different configuration, well, the path-only
links may no longer function. This is a small risk, however: it's likely
you'll be able to configure the new server appropriately.

Probably the more important thing, particularly from your visitor's
point of view, is consistency. Don't use
http://www.example.com/foo/index.html in some cases and
http://www.example.com/foo/ in others ... if you intend them to refer to
the same document. From the browser's point of view, they are different
documents, which affects caching and visited-link highlighting.
But if I'm attempting to develop and test a complete web site on my own
(Mac iBook OS 9) computer before uploading it to my university's server,
I can't do this, because subdirectories are folders in this environment
and as best I can tell browsers operating on my own machine can't link
to folders as URLs.

Q3: If this is correct, is there any way around it?

No: the browser has nothing to do with it (almost: the exception is when
the browser request is a path but doesn't end with a forward-slash).
Default documents are handled by a webserver, not by the browser. You
need to run a webserver on your laptop. I'm not sure if one is
included/available for OS9, but OSX comes with Apache and easy setup
instructions.

--
Joel.

http://www.cv6.org/
"May she also say with just pride:
I have done the State some service."

[Stan Brown]

"AES/newspost" <si*****@stanford.edu> wrote in
comp.infosystems.www.authoring.html:

My understanding -- I'm not an expert -- is that on (some? many? all?)
standard Internet servers a URL can point to a subdirectory name
followed by a backslash, and that links to this URL will automatically
go to an "index.html" file located in that subdirectory, if there is one.

Q1: Is this more or less correct?
Less. :-) The backslash is a Microsoftism for paths in Windows and
DOS. In URLs the separator is a slash.

For instance,
http://www.acad.sunytccc.edu/instruct/sbrown/stat/
gets the index page for my statistics course.

A couple of notes:

a. The page may or may not be called "index.htm". That varies by
server, so you should find out what the "default page" is for your
server.

b. Some servers are set up that if there's no default page present,
a URL in the above form gets a directory listing, and then the
visitor can choose by filename. Generally that's not a helpful
interface, so it's usually good practice to make sure every
directory has a default page present.
Put the web pages associated with some specific
or isolated subtopic into an appropriately named subdirectory (or
subsubdirectory) within the main web site's top level directory; use an
index.html

Q2: Is this good advice?
Generally yes. I think for novice Web authors we can drop the
"generally". :-)

Advanced authors play all sorts of games with URLs, because the URL
doesn't necessarily have to reflect a directory structure.
But if I'm attempting to develop and test a complete web site on my own
(Mac iBook OS 9) computer before uploading it to my university's server,
I can't do this, because subdirectories are folders in this environment
and as best I can tell browsers operating on my own machine can't link
to folders as URLs.

Q3: If this is correct, is there any way around it? (at the Mac OS 9
level, or if I upgrade to Mac OS X)

You can install a server on your computer, and if you're doing
serious Web development you probably want to. I don't know of
specific Mac software to suggest, though.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/

[AES/newspost]

In article <MP************************@news.odyssey.net>,
Stan Brown <th************@fastmail.fm> wrote:

I'm attempting to develop and test a complete web site on my own
(Mac iBook OS 9) computer before uploading it to my university's server,
I'm limited in doing this because subdirectories are folders in this case
and as best I can tell browsers operating on my own machine can't link
to folders as URLs.

Q3: If this is correct, is there any way around it? (at the Mac OS 9
level, or if I upgrade to Mac OS X)

You can install a server on your computer, and if you're doing
serious Web development you probably want to. I don't know of
specific Mac software to suggest, though.

Thanks for these comments (and those from others) (and my reference to
backslash was a careless error -- been doing too much TeXing).

Just one followup: Using Netscape (only browser I've ever used) I can
open the top level index.html file in the "web site" folder on my HD, or
in fact open any html file within the nested folder structure in that
web site folder, and view it as a web page.

Once that's happened, moreover, I can properly follow properly coded
relative links up and down throughout that (psuedo) web site, and also
follow absolute links to outside sites as needed. By doing this, I can
test my site to assure that all its links, relative and absolute, will
function properly when its full contents (including subfolders) are
uploaded to my university's site -- and this test can be done without
any separate server being present on my computer.

This only works, however, if all the relative links in my web site
folder point only to other files, not subfolders, within this web site
folder. I'm hypothesizing that Netscape _could_ at least in principle
be made smart enough to follow relative links pointing to subfolders as
well as to files, following the index.html convention, but just isn't
programmed that way; and I'm wondering if any other (Mac-based) browsers
are.

[Alan J. Flavell]

On Sun, 1 Aug 2004, AES/newspost wrote:

Just one followup: Using Netscape (only browser I've ever used)
Oops, that's a rather telling comment...
I can open the top level index.html file in the "web site" folder on
my HD, or in fact open any html file within the nested folder
structure in that web site folder, and view it as a web page.
Don't do it. Many of the best practices will fail to work in this
situation. I really can't recommend anything less than installing a
local web server of some kind.
This only works, however, if all the relative links in my web site
folder point only to other files, not subfolders, within this web site
folder.
Just so. Handy things like href="../" and so on will simply fail to
work. Spelling out index.html in an href is messy, and causes
problems when you want to change to something else (index.php or
whatever).
I'm hypothesizing that Netscape _could_ at least in principle
be made smart enough to follow relative links pointing to subfolders as
well as to files, following the index.html convention,
You're just trying to design yourself into a corner, is the way that I
see it.
but just isn't programmed that way; and I'm wondering if any other
(Mac-based) browsers are.

That isn't how the web is designed to work. Knowledge of how to
resolve a URL into actual resources resides in the server (and its
configuration), not in the client. Attempts to work around that lead
to too many restrictions. Several colleagues tried it despite my
advice to the contrary - I've seen the problems that they experienced.

I can't comment on your specific platform, but a colleague who runs OS
X changed to running a local version of Apache and hasn't regretted
it.

[Stan Brown]

"AES/newspost" <si*****@stanford.edu> wrote in
comp.infosystems.www.authoring.html:

(about testing a Web site on a local computer without installing a
server)

Using Netscape (only browser I've ever used) I can open the top
level index.html file in the "web site" folder on my HD, or
in fact open any html file within the nested folder structure in that
web site folder, and view it as a web page.
Well, yes. Sorry -- I thought you were already aware of that. Any
browser I know of can do that.

Not only that, in most browsers you can bookmark a local file, so
you don't have to reopen the file manually if you test it
frequently.
This only works, however, if all the relative links in my web site
folder point only to other files, not subfolders, within this web site
folder.
True. Just be sure you're consistent in all internal references.
Browsers generally don't know that blahblah/ and blahblah/index.htm
point to the same resource, so they may not be able to use the
cached copy of one if you reference the other.
I'm hypothesizing that Netscape _could_ at least in principle
be made smart enough to follow relative links pointing to subfolders as
well as to files, following the index.html convention, but just isn't
programmed that way;

In principle any software can do anything, but even in principle the
"feature" you suggest would be a mistake.

Different sites use index.htm, or index.html, or default.htm, or
default.html, with different rules about which one takes precedence
when more than one is present. A browser would have no way to know
these rules, and if it tried to guess it would guess wrong.

When your browser requests
http://www.acad.sunytccc.edu/instruct/sbrown/stat/
it is saying "give me the main pagen in that directory"(*) -- the
site knows what is the main page but the browser does not (and
should not).

(*) That's an oversimplification, but for this discussion I'm
assuming that the site has files organized into directories and that
the URLs reflect that structure. As I mentioned earlier, that may or
may not be true -- it's under control of the site designer.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/

[Stan Brown]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in
comp.infosystems.www.authoring.html:

Just so. Handy things like href="../" and so on will simply fail to
work

True, but is that really so terrible? (That's an honest question,
not a disagreement.)

At my college I'm stuck with an IIS server, so all my index pages
are called default.htm. I code e.g. "../default.htm" instead of
"../" everywhere, so that I can test locally.

Granted, it's 11 extra characters in a few URLs. But, as has been
pointed out here, even a very small image will likely swamp all such
byte wastage.

I agree with you that "../" is cleaner and more aesthetical(*) than
"../default.htm", but is it really a problem for the visitors? All
they care about is clicking on links(**) and having them work, which
they will.

(For me as author it's not a problem. I have a preprocessor macro
#define indexpage default.htm
and the day I install Apache, or the day the college gets better
server software, I can just change it in the one file of
definitions, type "make", and then upload all the revised pages.)

(*) Is "aesthetical" a word?

(**) Oops, I mean "selecting links". :-)

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/

[Alan J. Flavell]

On Mon, 2 Aug 2004, Stan Brown wrote:

At my college I'm stuck with an IIS server, so all my index pages
are called default.htm.
Not .asp? (SCNR)
I code e.g. "../default.htm" instead of
"../" everywhere, so that I can test locally.
Think about what happens if and when there's some reason that you need
to change that. Worse - folks who have bookmarked your site will have
to change too. IMHO that is imposing an unnecessary constraint on
your readers - for no better reason than your own convenience.

Even if you can rewrite your own site at the click of a macro
processor - think about those other links. (What will the indexing
robot do for your external link rating when it finds that the old
links into your site now point to a 30x redirection, or worse, to a
404 not found?).
Granted, it's 11 extra characters in a few URLs. But, as has been
pointed out here, even a very small image will likely swamp all such
byte wastage.
Oh, sure, fully agree with _that_ bit. Shorter URLs are nice to have,
but a relatively small advantage, and by no means the chief reason for
recommending "./" and friends.
I agree with you that "../" is cleaner and more aesthetical(*) than
"../default.htm", but is it really a problem for the visitors? All
they care about is clicking on links(**) and having them work,

Bookmarks to your site. Other people's links to your site.

No: I'm definitely on Dan's side of the fence on this issue:

http://webtips.dan.info/subdir.html#LinkHome

cheers

[Philipp Lenssen]

Alan J. Flavell wrote:

No: I'm definitely on Dan's side of the fence on this issue:

http://webtips.dan.info/subdir.html#LinkHome

After reading through that part, what do you have against linking back
to the homepage via "/" (this is what I do too)? Or did I misunderstand
this.

--
Google Blogoscoped
http://blog.outer-court.com

[Kris]

In article <MP************************@news.odyssey.net>,
Stan Brown <th************@fastmail.fm> wrote:

Q3: If this is correct, is there any way around it? (at the Mac OS 9
level, or if I upgrade to Mac OS X)

You can install a server on your computer, and if you're doing
serious Web development you probably want to. I don't know of
specific Mac software to suggest, though.

OS X has an Apache server pre-installed, which will be enabled when you
switch on Personal Web Sharing in Sharing/System Preferences.

--
Kris
<kr*******@xs4all.netherlands> (nl)

[Alan J. Flavell]

On Mon, 2 Aug 2004, Philipp Lenssen wrote:

After reading through that part, what do you have against linking back
to the homepage via "/" (this is what I do too)?

Excuse me? If I gave the impression that I had anything against
linking to the site's "home"[1] page like that, then it *was* a
misunderstanding.

I do have a problem though with the use of the word "back" in that
context, In conventional browsing terminology, "back" means "pop the
URL history stack". There's no reason that the reader has ever
visited that page before - many of them enter the site at a targetted
page, thanks to a search engine (as we can see from the server logs)
without having ever visited the "home" page, so it's illogical to
suggest to them that going to the home page will necessarily
correspond to /their/ concept of "back".

But yes:

"./" refers to the default document at the current hierarchy level,

"../" refers to the default document at the next hierarchy level "above"[2]

"/" refers to the default document at the root of the current
(virtual) server.

These are all respectable relative URLs, and should refer to some kind
of overview or index document for the respective level. What the
document is called on the server is not known to the client, and does
not need to be known: it might be index.html or Default.htm or
Overview.php; or it might not exist at all, and be generated
automatically by the server. Whatever it is today, it might be
something different next week - but the URL will not need to change.

Have I made that any clearer? You might or might not agree, but at
least I would like to clear up any misunderstanding.

all the best

[1] Early web documents draw what seems to me to be a useful
distinction between a "home" page and a "welcome" page. See
http://www.w3.org/Provider/Style/Etiquette.html
under the heading "Welcome home?". It's a pity that this
useful distinction seems to have been blurred with time.

[2] "above" in the sense of the conventional view of a hierarchy which
is rooted at the top - contrary to the botanical view ;-)

[Harrie]

Alan J. Flavell said the following on 02/08/2004 18:48:

"./" refers to the default document at the current hierarchy level,

"../" refers to the default document at the next hierarchy level "above"[2]

"/" refers to the default document at the root of the current (virtual)
server.

These are all respectable relative URLs

Is the last one a relative URL? If so, is that because their might be
(a) virtual server(s) involved?

I was under the impression that the last one is an absolute path, in
this case without a protocol and servername part.

Regards,
Harrie

[Alan J. Flavell]

On Mon, 2 Aug 2004, Harrie wrote:

"/" refers to the default document at the root of the current (virtual)
server.

These are all respectable relative URLs
Is the last one a relative URL?

It's "relative" in the sense that it needs to be completed by adding
the protocol, host (and port, if other than 80) parts to make it into
an absolute URL.
I was under the impression that the last one is an absolute path,

You're absolutely right ;-)

Or "absolute URLpath", as some would say

But it's still a kind of "relative URL".

all the best

[Harrie]

Alan J. Flavell said the following on 02/08/2004 20:48:

On Mon, 2 Aug 2004, Harrie wrote:

Alan J. Flavell said the following on 02/08/2004 18:48:

"/" refers to the default document at the root of the current
(virtual) server.

These are all respectable relative URLs

Is the last one a relative URL?

It's "relative" in the sense that it needs to be completed by adding the
protocol, host (and port, if other than 80) parts to make it into an
absolute URL.

I would call that full qualified, but I kind of deduced that from FQDN.
Not sure what the proper word for it is, somebody knows?

Best regards,
Harrie

[Brian]

Stan Brown wrote:

At my college I'm stuck with an IIS server
Oh, I'm sorry. I can't believe they are that reckless, too. My server
logs used to show a constant barrage of attacks by the Nimda and Code
Red worms looking for IIS servers to exploit. (A bit of redirection
changed that!)
so all my index pages are called default.htm. I code e.g.
"../default.htm" instead of "../" everywhere, so that I can test
locally.

Granted, it's 11 extra characters in a few URLs. But, as has been
pointed out here, even a very small image will likely swamp all such
byte wastage.
That's not the biggest problem. A.Flavell has pointed out many of them.
I'll add that /foo/ != /foo/default.htm in terms of the www, even if
they are the same on your server with your configuration. Will clients
ever request /foo/ and then later /foo/default.htm (via your relative
links)? I'm thinking especially of the root directory, which might be
linked from Google or the like.

My problem was with awkward links like "../../../css/style.css" where
I'd have to change the link if I moved the page to new level. I gave up
and installed Apache, and never regretted it.
(**) Oops, I mean "selecting links". :-)

Shame on you!

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Claire Tucker]

On Mon, 02 Aug 2004 23:07:14 +0200, Harrie
<di******************@hotmail.com> wrote:

Alan J. Flavell said the following on 02/08/2004 20:48:

On Mon, 2 Aug 2004, Harrie wrote:

Alan J. Flavell said the following on 02/08/2004 18:48:

"/" refers to the default document at the root of the current
(virtual) server.

These are all respectable relative URLs

Is the last one a relative URL?

It's "relative" in the sense that it needs to be completed by adding the
protocol, host (and port, if other than 80) parts to make it into an
absolute URL.

I would call that full qualified, but I kind of deduced that from FQDN.
Not sure what the proper word for it is, somebody knows?

I suppose you could call it a qualified *path*, but it isn't a
fully-qualified *URL*, since there is information missing from it.
(protocol and host)

While not the technical term, lots of people seem to call them
"root-relative" URLs.

RFC 1808 seems to call this class of relative URLs an 'absolute path',
and since this RFC is titled "relative URL syntax" I think we can
consider it to be a good source.

Note also that there is another class of relative URL, starting with
two slashes, which allows you to omit the protocol but specify the
hostname:

//www.myhost.com/path/to/resource

....which I suppose comes in useful when content is mirrored between
cleartext HTTP and an SSL HTTP servers to retain the 'http' or 'https'
as appropriate while still changing the hostname.

All the best,
-Claire

[Pierre Goiffon]

"Stan Brown" <th************@fastmail.fm> a écrit dans le message de
news:MP************************@news.odyssey.net

At my college I'm stuck with an IIS server, so all my index pages
are called default.htm. I code e.g. "../default.htm" instead of
"../" everywhere, so that I can test locally.

As far as I know thes default document could be changed in every IIS
version, workstation or server. But on IIS there's no .htaccess so very
often the administrators don't want to change this for their users... in
fact this could be done via the IIS operators (a IIS right that permits
remote users to open the IIS MMC for a particular website or not, remotely
or not), but I've rarely seen this used.

[Harrie]

Claire Tucker said the following on 03/08/2004 03:33:

On Mon, 02 Aug 2004 23:07:14 +0200, Harrie
<di******************@hotmail.com> wrote:

Alan J. Flavell said the following on 02/08/2004 20:48:

It's "relative" in the sense that it needs to be completed by adding the
protocol, host (and port, if other than 80) parts to make it into an
absolute URL.
I would call that full qualified, but I kind of deduced that from FQDN.
Not sure what the proper word for it is, somebody knows?

I suppose you could call it a qualified *path*, but it isn't a
fully-qualified *URL*, since there is information missing from it.
(protocol and host)

I was refering to:

<scheme>://<net_loc>/<path>

... as full qualified, but now I read it back that's not very obvious.
While not the technical term, lots of people seem to call them
"root-relative" URLs.
From a filesystem viewpoint this isn't making much sence, anything
referenced from the root is absolute, but, ofcourse, the web is not a
filesystem.
RFC 1808 seems to call this class of relative URLs an 'absolute path',
and since this RFC is titled "relative URL syntax" I think we can
consider it to be a good source.
Thanks for mentioning the RFC, I'll look it up.
Note also that there is another class of relative URL, starting with
two slashes, which allows you to omit the protocol but specify the
hostname:

//www.myhost.com/path/to/resource

...which I suppose comes in useful when content is mirrored between
cleartext HTTP and an SSL HTTP servers to retain the 'http' or 'https'
as appropriate while still changing the hostname.

Ok, this is absolutely new for me. I have some reading to do :)

Thanks for your input Claire, it's much appreciated.

Best regards,
Harrie

[Stan Brown]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in
comp.infosystems.www.authoring.html:

Think about what happens if and when there's some reason that you need
to change that.
If you mean what happens to me, no problem.
Worse - folks who have bookmarked your site will have
to change too.

Hmm -- I didn't think about the bookmarks. That's a valid point, I
agree. It's probably not terribly important in my specific case,
since students are given the URLs with terminal / and told to
bookmark them. But in the general case it could be a problem.

And in my specific case I guess caching issues are a problem. If
they select their bookmark for
http://www.acad.sunytccc.edu/instruct/sbrown/stat58/
and then click on, say, "broadcast e-mails", then click on the
breadcrumb for "sec[tion] 58", their browser will probably request
http://www.acad.sunytccc.edu/instruc...58/default.htm
because it's a different URL from the one they started with.

Okay, I'm convinced. I'll fix that, before the start of the fall
semester.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/

[Stan Brown]

"Pierre Goiffon" <pg******@nowhere.invalid> wrote in
comp.infosystems.www.authoring.html:

But on IIS there's no .htaccess so very
often the administrators don't want to change this for their users.

That's my situation. The server I use or course-related Web pages is
a political football between departments. Nobody really wants to
become expert in administering it, so nobody is willing to do
anything out of the ordinary because they can't be sure it won't
blow up in their face.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/

[Pierre Goiffon]

"Stan Brown" <th************@fastmail.fm> a écrit dans le message de
news:MP************************@news.odyssey.net

The server I use or course-related Web pages is
a political football between departments. Nobody really wants to
become expert in administering it, so nobody is willing to do
anything out of the ordinary because they can't be sure it won't
blow up in their face.

And that's a pitty. IIS is one of the best product I ever used, but it is
very often under use, working as it can without a well qualified admin.
Well, good luck then :)