I have a lot of information on my computer. This is intentional. I wanted to have an electronic library and file system so that I wouldn’t have to carry a lot of paper around with me. But how to make it usable?
On Windows, a desktop (graphical) app named “Explorer” is the tool provided to navigate the file system. It basically just shows you the file tree and gives you ways to move around on it. You can even make it show you little previews of files when you select them, if you know how to set that up.
But I was not happy with this. I have been learning how to combine related files from several different locations into a single document that covers a particular subject. I wanted those files to be an active part of my file system, and Explorer didn’t seem to have the browser functionality to pull this off.
Personal Web Server
I knew from my school projects that I could have a web server on my own computer. It couldn’t serve pages to the internet, but it could serve them to my own browser, and to an intranet (local network) if I had one. I also knew that the browser could view web-compatible files locally without a server.
Index Page Strategies
I thought I would need to build HTML index pages just to view lists of all the different files on my machine. This would have to be a dynamic page. I thought it would have to exist outside of the document root, so couldn’t use PHP. But Java Script does not support interrogation of the local file system from the browser (for good reason) though there are ways to build upload forms that do this. So it had to be a server-side (PHP for me) solution. I found that you can use PHP to scan directories that are outside of the document root. But anchor tags made in this way don’t work right. You can’t do hypertext jumps outside of the Document Root when your browser is talking to a web server.
Where to put document root?
At school we uploaded our files to a Linux server that contained an active user directory for every IT student that needed one. This setup took advantage of an Apache Web Server feature known as “userdir.” However, this feature was not explained to us. It was just noted that if we wanted a file to be “public” (And they WERE public! Anyone on the internet could access those school sites.) then the files had to go in a folder named “public_html.” Non-public files should go in other directories. I mimicked these folder names on my own computer so that adjusting path names would not be too difficult.
But at that time I didn’t understand what the documentroot setting in Apache Web Server was all about.
Most Common Pattern
After some reading I began to see that we were not using a “normal” setup at school. It’s a little hard to find this info on the web, because most sites either assume you don’t know much and really don’t want to or assume you know it all. But I found an Australian site devoted to web site administrators that discussed this more thoroughly. Most commonly, the server is set up to serve just one site. On a public site, the server name is usually some version of the web site’s domain name. You set aside one directory on that machine for your public files (html) and that’s your document root. Program files, etc, usually reside on the same machine, often on the same drive (and in Linux it’s all one big file system anyway), and the server will not allow any public access to those files if they are not in its document root folder.
So what does the developer do? He or she can set up a “development” server that has the exact same file structure as the “production” server. The site can be developed either locally, then uploaded, or directly on the “dev” server, then moved over to the “prod” server when the time comes to do that.
What if the developer wants to work on several sites on the dev machine that will each be deployed to a single-site server later? One answer is to employ virtual servers. Most modern web servers can actually serve several different web sites on the same physical computer. This is dome by setting up virtual servers on the web server. Each server gets its own name, which would be the name that the browser would use to access it. This is similar to how “userdir” works on Linux machines, but takes a little more setup.
But if the developer’s machine is not on a public network, or at least behind a firewall, then the security issues that exist with a real public server are not that important. So you have the option in this case to push back the document root deeper into the file system.
Being inside Document Root
Expanding the number of files in the document root has some interesting advantages:
1) Any directory without in INDEX.HTML (or INDEX.PHP) file in it will have a temporary index made for it by the browser. This gives you basic navigation functionality similar to Windows Explorer.
2) Any HTML found will be served as a web page.
3) Any PHP scripts will also work, if you have PHP (etc.) on that web server.
4) Everything in Document Root can be part of any page. It’s like a mini WWW on your own computer. You can also call any WWW resource, if your have a good internet connection.
I have all my data on a separate drive on my computer. So right now, that’s my document root. I can navigate the drive via my browser by going to http://localhost. Any html and most image files and media files will render and play right in the browser. I’m looking into the best ways to view Word docs and spreadsheets. For now I am using Universal Viewer as one way to have a viewing app that is a little lighter than a full file editing app. I think browsers should be able to handle any XML-type file without adding anything, but currently it doesn’t work that way.
SO that’s where things stand right now. More news later!