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.

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!

/jason

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?

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.

/jason

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)

Leos

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…

/jason

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.

Kip:

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.

/jason

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.

/jason

Kip:

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.

/jason