Not in the least bit, because you can't provide metrics on adoption based on random samplings and irrelevant information.

For metrics to be trusted, one of the fundamental requirements is that the data should be independently verifiable using the same techniques used by the publisher. It also needs to be comprehensive to the extent possible. We use DotNetNuke.com registration data for some portions of the report because it may be interesting to some, but since it is not available for review (obvious privacy concerns), we don't rely too much on it. A bulk of the report detail is from data that is available to anyone with a LOT of time, inclination, resources and patience to pull it together into a detailed report. Of course, that's only part of it. Then you have to analyze that data and put it in context by so those interested in DotNetNuke from a business perspective can get information that can help with their business strategy.

 Nik

What you are describing is a web service call between the server where the code is running and dotnetnuke.com. I already stated that web service calls do not work in Medium Trust. Therefore, this is not a solution.

The current solution sends an image tag in the html source to the client browser. So the call is actually made from the client browser to dotnetnuke.com to retrieve the image. The code on dotnetnuke.com compares the version parameter on the querystring with the latest version number in the database and serves either an invisible gif or checkbox gif, depending on the logic.

I believe I can actually solve your Gemini issue by including logic in the core framework which does not serve an image tag if the current request is running under SSL ( similar to the current logic which does not serve an image if the request is running on localhost ). This should solve the issue with the browser warnings when running under SSL.