last updated:

This is an HTTP log browser add-in for the control panel in Frontier 6.1.

What does it do?

It lets you view the entirety of Frontier’s HTTP (mainResponder) log for the current day, in hour-by-hour chunks. It also clearly shows you referrers (so that you can thank all those people who are pointing the way to you).

What does it look like?

Well, you’re in luck — we’ve got a screen shot.

How do I use it?

First of all, you have to be running your own Frontier server; it plugs in to the main configuration database of Frontier, so unless Userland installs this on EditThisPage.Com, you can’t use it there. (Besides, this is a browser for the entire HTTP log, and I would assume that the EditThisPage.Com logs get huge fast, which means that they’re probably tough to trawl through!) You also have to be using guest database logging; check at user.log.prefs.flLogToGuestDatabase to make sure that it’s set to true.

Download the attachment from this message (the links are above, in the header), and import it into your copy of Frontier. (The easiest way to do this is to click on the fat page link above, then save the HTML page that comes up with the File/Save As… command in your browser, and then open this page in Frontier.) You should put the table that you’re importing into Frontier at the address config.mainResponder.controlPanel.wizards.LogBrowser. (The wizards table is where the control panel looks for add-ins.)

Once you’ve installed it at that location, you should be all set to go — load the control panel (, and you should see a section between Settings and Readouts in the left-hand navigation column for Add-ins, with a link to LogBrowser underneath. Click on it, and away you go.

What makes this different from the HTTP readout?

A few things. The HTTP readout that’s already part of the control panel only shows you the current hour; the Log Browser will show you the entire current day, hour by hour.

Additionally, the Log Browser explicitly shows you the web page that referred each hit to your site, whereas with the HTTP readout, you’ve got to mouse over the small asterisk and look in the status bar of your web browser.

Lastly, the Log Browser omits a few columns that the HTTP readout includes — HTTP status code, page size, and load time, to name a couple.

In the end, it’s a matter of preference which one you use. I designed this one because I wanted the specific information that it provides.

What if I find a problem?

You can mail me with any bugs that you discover, and I’ll do my darndest to fix ‘em!


I designed this on a Windows-based machine, and because of the difficulty of squeezing all the necessary text into each line, I made an explicit choice to specify a font in the Log Browser. I use Arial Narrow, and I fess up that I have no clue if it exists on the Mac side. If it doesn’t, then I would love suggestions as to what font I should specify for people who are on Macs. (Just mail me.)

Update: 01/11/2000

There was a small problem with this add-in and MSIE on the Mac; I think that I have fixed it. (MSIE on the Mac seems to have an odd behavior with search and post strings on URL links.) The copy that’s attached to this message is the updated copy.


Good work! I have it running here, no problems installing it, seems to run like a charm.

I’ve had GDB logging turned off until now, and I’ll have to watch the memory consumption, but this is a good reason to turn it on. :o)

Thanks for releasing it.

• Posted by: Andrew Duncan on Jan 8, 2000, 2:40 AM

I’m glad that it’s working well.

I’ve never had any problems with guest database logging and memory — actually, before GDBs had really been worked out, we did, but since they came into their own, we’ve been flyin’ high. We’ve got three production machines that log into the GDB and haven’t been rebooted in months.

Keep me posted about any problems that crop up!


• Posted by: Jason Levine on Jan 8, 2000, 5:55 AM

This is great. Just what I was looking for. I’ll install this as soon as I get to the office.

Thanks, Leos

P.S. Do you think there is a way to adapt this to look at logs of days other than the current day?

• Posted by: Leos Kral on Jan 8, 2000, 9:30 AM

It would be easy as pie to adapt, but the problem is that all of the old logs that are opened by the add-in would stay open without me explicitly closing them, and I haven’t worked out a good logic to the closing process yet (in my head). Suggestions are encouraged; the main questions I have are:

  1. do you open a log file, parse it, and then close it right away?

  2. if so, you know that people are going to be clicking on all of the hours individually; do you just suck up the overhead of opening and closing the log each time?

  3. if not, what kind of logic do you use to decide when it’s safe to close the log?

  4. what do you use to implement this logic? I could launch a thread that sleeps for X amount of time and then closes the log; with a few people pounding on the old logs, though, you’d end up with threads just hangin’ out on that machine. Not a biggie, but a consideration.

Just some questions; please feel free to contribute answers, or other questions, and we’ll get this one ironed out right quick.


• Posted by: Jason Levine on Jan 9, 2000, 12:52 AM

Assuming the rendering is done through the same processes that show the current day’s log, how about a list of dates at the bottom of the page showing which day logs are opened with a close button by each.

I am assuming here that log views are used only by the administrator who has controlPanel privileges. If you want to give access to users than that becomes more complicated.

I would opt for a “close file” button and close any file automatically if it has remained open for some specified period of time (24 hours if just administrator views files or an hour or less if multiple users view files)


• Posted by: Leos Kral on Jan 9, 2000, 12:43 PM

This sounds like a good idea, all in all — I actually thought more about it last night, and it seems like when a file is opened, either I could start a separate thread that slept until it was time to close it, or I could add an entry to a table that an agent checked once a minute to see if it should be closed. Then, your idea about an explicit close button would give you the opportunity to preempt the whole process.

Something to work on when I return…


• Posted by: Jason Levine on Jan 9, 2000, 11:02 PM

I must be really dense this morning. I tried to install this via the RPC mechanism and got the following error:

Can’t process the request because a Frontier value of type “address” can’t be represented in XML-Data at this time.

I then tried the fat page and loaded it in Frontier and got the following error:

Can’t import to [“C:\Program Files\Frontier 6.1\Guest Databases\apps\config.root”].config.mainresponder.controlPanel.wizards because the table doesn’t exist.

I noticed that I have my Frontier installed in “C:\Frontier 6.1”, so I changed the prompt to reflect that. No dice, same error.

Then I went and opened my config.root and looked to config.mainresponder and I see no controlpanel listed there. I have callbacks, data, domains, globals, prefs, search, stats, and urls.

Is there some other package I need to install first to enable controlPanel add-ins? Doing a search at userland hasn’t turned up anything. All I’ve found Control Panel Open Architecture and Jason’s first message about Add-ins for control panel.

Thanks for your time, I guess I’m suffering from Monday morning denseness.

Update: I noticed that even though I have auto-updates on my frontier.root, I was still on 6.1, a quick check at userland revealed that 6.1.1 is an update requiring a new .exe. I installed 6.1.1, but still get the same errors and my config.root still looks the same.

• Posted by: Kip DeGraaf on Jan 10, 2000, 9:26 AM


The RPC error is something that I don’t understand, simply because I’ve never used it. I’ll figure that one out when I get back to NYC.

As for the other one, you’re right — you don’t have the right table structure in place, and (while I think that it should) Frontier doesn’t set up all of the subtables for you. So what you need to do is make sure that all of the tables exist for the add-in to live in; this means that you need to create a table in config.mainResponder named controlPanel, and then create a table named wizards in that table. Then import the add-in (changing the pathname as you did, or just typing in config.mainResponder.controlPanel.wizards.logBrowser, since Frontier will figure out that config.root exists in a guest database.


• Posted by: Jason Levine on Jan 10, 2000, 8:29 PM

I fixed a small problem with the Log Browser add-in and MSIE for the Mac today; the copy of the add-in that’s attached to the main message is the corrected version.


• Posted by: Jason Levine on Jan 11, 2000, 8:40 PM


Okie dokie — as for the error message that you were seeing when trying to download the attachment via RPC (Can’t process the request because a Frontier value of type “address” can’t be represented in XML-Data at this time.), that was because I interpreted a Frontier doc incorrectly. It’s fixed now.

For future reference, if you’re attaching things to Manila discussion group messages, the enclosureAddress object is not an address, but rather a string.


• Posted by: Jason Levine on Jan 12, 2000, 1:35 AM
Please note that comments automatically close after 60 days; the comment spammers love to use the older, rarely-viewed pages to work their magic. If comments are closed and you want to let me know something, feel free to use the contact page!