When you install and run QRecall for the first time under Leopard, it asks:

Do you want the application "QRecall.app" to accept incoming network connections?

If you click "Allow", then you get asked about installing the scheduler. After that, you get a second instance of the first dialog, asking if "QRecall.app" should be allowed to accept incoming network connections. After clicking "Allow" again, then you're asked:

"Do you want the application "QRecallMonitor.app" to accept incoming network connections? Clicking "Allow" on that one finally allows QRecall to finish launching.

I realize these are "one-time only" questions, and I know that responding "Allow" causes them to be added to the Leopard firewall list. But what I don't understand is if they really do need to be allowed.

I know QRecall needs to be able to make OUTGOING connections in order to check with the update server. And I'm assuming that if it initiates an outgoing connection, the firewall will allow the incoming reply. Or is that not correct? If it is correct, then under what circumstances would something from the outside need to initiate a connection with QRecall? And why do I get asked twice about "QRecall.app"?

-- Bruce

Clearly, you've turn on the firewall.

Leopard is confused. I have no idea why it thinks QRecall implements any network services. This version of QRecall doesn't creating any incoming TCP sockets.

The only network communications at the moment is via the Sparkle framework that checks for version updates. Sparkle works over HTTP (port 80) and doesn't require any incoming access.

So in the end, it doesn't matter if you answer Deny or Allow, QRecall should work just fine. I'm trying to find out why Leopard thinks QRecall accepts network connections and how to get it to stop asking silly questions.

James Bucanek wrote:Clearly, you've turn on the firewall.

Yep.

Leopard is confused.

I'm glad to know I wasn't the only one.

I have no idea why it thinks QRecall implements any network services. This version of QRecall doesn't creating any incoming TCP sockets.

The only network communications at the moment is via the Sparkle framework that checks for version updates. Sparkle works over HTTP (port 80) and doesn't require any incoming access.

Well, QRecall isn't the only one that Leopard seems to be confused about. I've been asked that question for a lot of apps that I'm nearly certain don't really need incoming access. I see that I have entries in there for QRecall, QRecallMonitor, and QRecallScheduler. But I also have things like Safari, Cyberduck, BBEdit, and RealPlayer. I'm fairly certain none of those require incoming connections.

So in the end, it doesn't matter if you answer Deny or Allow, QRecall should work just fine. I'm trying to find out why Leopard thinks QRecall accepts network connections and how to get it to stop asking silly questions.

Actually, after sending my first message on this subject, I got asked about QRecall.app several more times while I was setting up a schedule via the assistant. As a matter of fact, I just tried to launch QRecall again, and it asked me again, so this time I said "Deny" just to see what happened. It changed the firewall setting from "allow incoming connections" to "block incoming connections", but it's a mystery to me why it was no longer willing to accept the answer that was already there.

Anyway, as you said, QRecall seems to work just fine with either setting.

QRecall 1.0.0(53) resolves this issue.

Upgrade to 1.0.0(53) using the QRecall > Check for updates... command.

James Bucanek wrote:QRecall 1.0.0(53) resolves this issue.

Confirmed. I removed the QRecall, Monitor, and Scheduler entries from my firewall list, then launched QRecall (after rebooting), and it didn't ask me about incoming connections at all.

QRecall launches *extremely* quickly now. In fact I use LaunchBar to launch it, and the QRecall QuickStart window appears before the LaunchBar "window" has even started to go away. Opening archives is much faster, too. I'm not sure if you did something in this version, or if it's been that way for a while and I'm just now noticing. (To be fair, I've been running it on an Intel Mac for only a couple of weeks, and most of that was automatic schedules, so I hadn't spent a lot of time actually launching QRecall or opening archives.)

-- Bruce

Bruce Giles wrote:Confirmed.

That's good to hear.

QRecall launches *extremely* quickly now. ... (To be fair, I've been running it on an Intel Mac for only a couple of weeks, and most of that was automatic schedules, so I hadn't spent a lot of time actually launching QRecall or opening archives.)

The scheduler management logic is much cleaner now; the client application spends almost no time during start up making sure things are in order.

The major speed improvements in opening archives was rolled into 1.0.0(49), so maybe you just hadn't noticed yet.