Recommended implementation for a desktop web monitoring client?

Question

Background

I have a business idea, one component of which involves a client that would be downloaded & installed by thousands of users via a web page.

Application Requirements

Version 1:

The application must:

• monitor internet usage on the user's desktop with the following areas monitored:

  • browser used,
  • hours used
  • sites accessed
  • takes into account which browser tab is 'active'

• Produce a report of this usage (in CSV or another easily exportable format)

• It needs to be easily monitored by the user (e.g., in Windows via an icon in the system tray allowing the user to pause or stop the program).
• Easily upgradable via automatic updates.
• Needs to be lightweight with regards to memory usage.
• Needs to be easily and quickly installed,
  • Must be able to be uninstalled completely.
• Cannot adversely impact browser or user's system performance experience

For Version 2:

• be able to present graphical outputs (pie & bar charts)
• be multi-platform (version 1 will target Windows only)
• Integrate an online component

Question

Given these requirements, what technical implementation would you recommend, and what platform/language architecture would you recommend? The key aspects are functionalities and broadly defined low impact on users. ETA or cost are less critical.

Answer 1

Sounds like C# would suit your needs, as long as it's limited to a Windows client.

Answer 2

Qt and C++ are good for cross-platform clients -- esp. if they need to be "memory frugal" in a way that no solution in a garbage-collected language (i.e. basically all others;-) usually is.

Answer 3

I built something very similiar to this last year. I used C#. Initially it leveraged some of the 3.5 framework, but I had to scale it back to the 2.0 framework due to installation size restrictions. It's currently monitoring about 13,000 machines. collecting and sending back to a report server around 3MB of data per minute.

The client machines range from Pentium 4 boxes with 256MB of RAM running XP on up to dual core 2GB machines.

The app I built was not to be touched by the end user, so it runs as a combination of a windows service and a browser helper object plug in for IE. The BHO was necessary to capture exactly what was going on in the browser.

The only real challenges were in making it work under XP and Vista (all service pack levels) and in IE 6 and 7. XP and Vista have different security implications to take into account; IE 6 and 7 also have different access models.

Finally, we punted on dealing with Firefox or other browsers because the customer just didn't care about it.

UPDATE

Firefox only supports javascript, c++, and xul to code extensions in; using c# would be a complete PITA. I'd probably try javascript if it would do what I needed just because it's easier.

As far as Chrome, they only recently started supporting extensions (March 19,2009). You have to change the shortcut startup properties to even be able to run them. So, I'd probably skip that browser until it matures a bit. I imagine there will be a lot of changes to how plugins are built for it over the next year.

Concerning the amount of data per minute, that's an aggregate value. Each individual client only checks in once every fifteen minutes or so; or upon reconnect to the network when working disconnected. So, individual traffic is pretty low and has no impact on the user experience.

Firewalls

The reason a firewall really doesn't matter for us is that the data is transmitted back to our reporting server over port 80 using web services. If 80 is blocked, then they can't browse anyway so there's nothing to collect... As far as bandwidth, limit what you collect and broadcast back out. XML with long descriptive attribute / value names are NOT your friend.