home / articles / frontpage

The Personal Web Server - A Learning Curve Worth the Climb

For my first article, I'd like to talk about the Personal Web Server which comes with FrontPage. Many people have had difficulty understanding this piece of software; yet without it, FrontPage wouldn't provide much of the functionality which sets it apart from so many other website development tool kits. So, before you decide to chuck the Personal Web Server out the window, and leave yourself with a WYSIWYG editor, and nothing more, let's just take a look at this beast, and find out why it's really such a beauty.

Actually, FrontPage 97 comes with two servers: the FrontPage Personal Web Server (I will refer to this as "FP PWS"), and the Microsoft Personal Web Server (which I'll refer to as" MS PWS"). Believe me, you would rather use the MS PWS. I'll get to that later. First, let's talk about what a web server is, and what it does:

The Internet is a gigantic peer-to-peer network of computers, and when you're logged on to the Internet, you're actually a part of that network. Any peer-to-peer network requires the use of "servers" to manage access to files, folders, and even hardware and software. Why is it called a "server?" Because it "serves" all of this stuff to other (client) computers. A web server is a kind of network server, with special characteristics for WWW networking. It handles permissions (who can do what with which stuff), executes programs, communicates with and keeps track of "virtual directories" (those folders with '/'s instead of '\'s), and communicates with client computers which are making requests for files and actions from the server's computer.

So, why do you need one? Good question. Here's what the Personal Web Server does for you:

• Allows webs to be published as a whole, with a single command.
• Publish from local to remote, remote to local, or remote to remote websites.
• Provides the functionality of CGI, IDC, ASP, ISAPI programs, and the FrontPage WebBots on your local computer, so that you can test your webs locally in your browser before making them public. All of these technologies require a server and/or FrontPage server extensions to run.
• Provides "smart" web management. FrontPage uses special "_vti" files to keep track of what changes have been made, when, and by whom. When you publish using the "changed pages only" option, FrontPage knows which ones to publish. This can save you a lot of time and trouble.It also knows whether you have any broken links, and can inform you of such. You can manage a remote website just as easily as a local one, even edit files as if they were on your computer. FrontPage makes no diffference between local and remote webs - it always communicates through the server.
• Set permissions and properites of webs and folders. FrontPage communicates with the server to do this. Especially important if you want to use interactive technology, such as CGI, IDC, or ASP.
• Sets up virtual directories on the server.
• You can actually browse your webs from another computer on the Internet, when you are logged on. This can be handy for demonstrating them to clients, friends, etc.

So, you can see why having a server is awfully handy. Why do I recommend MS PWS over FP PWS? Because it has a whole lot more functionality. You can run IDC, CGI, and ASP with MS PWS. It is actually a scaled-down version of IIS (Microsoft's Internet Information Server, the "world class" server found on many hosting services).

What's the hardest thing about using the web server? Well, it seems that the biggest problem most people have is publishing with it, especially for the first time. So, here's the lowdown on most publishing situations:

If you're publishing to a domain (a "Root Web") for the first time, your hosting service will have to set up the FP extensions for you on that web. These extensions are not only used for WebBots, but for publishing and managing webs. Your hosting service will give you a user name and password for accessing your remote web site.

Open your local web and select File|Publish FrontPage web from the menu. FrontPage will want some information from you:

1. Destination Web Server: This is the domain name or IP address of the remote website. A domain name is actually a text equivalent of an IP address. For example, I have a webiste at http://www.connectrans.com/takempis. I would enter "www.connectrans.com" in this box.
2. Name of FrontPage Web: If you're publishing to the root web, you would type "<Root Web>" (In FrontPage 97 - In FrontPage 98, you would leave it blank). If you're publishing to a child web, you would type in the name you want to give to the child web. In my example, I would type in "takempis."
3. Add to an existing FrontPage Web: The only time you wouldn't check this box is if you're creating a new child web. As I said before, if you're publishing for the first time to a root web, the hosting service must set up the server extensions for you. This creates an empty FrontPage web.
4. Changed pages only: If you're publishing for the first time, leave this unchecked. That makes sure that all of the web will be published.

Hit the Okay button and you're off and running. You will be prompted for your user name and password. FrontPage takes care of the rest.

There are any number of other things which you will eventually learn about the server. Knowing how web servers work will make you a better web site developer. However, I think this should give you a head start. I can't begin to tell you what a time-saver FrontPage can be when you "bite the bullet" and climb that learning curve. But stick with it, and you'll find out for yourself.

Author: Kevin Spencer
Date: 9/26/97

More articles about Microsoft FrontPage
More articles by Kevin Spencer
Author Biography