Thank you for the feedback, Martin. Apparently we can't do this at eclipse.org presently. So I'll wait for the Board to make their decision before I spend any of my time of this.
-- Regards, Igor On 2013-09-05 6:54 PM, Oberhuber, Martin wrote:
Hi Igor, This sounds very interesting ! Several companies / plugins do this already with their own methods (I remember Max Andersen's EclipseCon talk about JBoss tools [1], Pydev and Subclipse also do it from what I remember). I really like the idea of providing common infrastructure under Eclipse.org custody for these kind of things rather than everyone doing their own. Just two thoughts, 1. As a commercial vendor of Eclipse-based tools, we'd probably disable the feature in our offering such that we don't offend those of our customers who are particularly paranoid and/or use our tools in secured labs without Web access; so in order for yourself to get reasonable statistics you should collect the product/branding ID along with the active plugin count. If you know that your plugin is in vendor X's tool but you don't get data from vendor X's product ID you'll get some idea how you have to correct your data. 2. At one customer of ours, the Pydev "call home" functionality caused nasty side-effects with the customer's authenticating web proxy and Equinox Secure Storage (forcing a login dialog on every Eclipse launch ... wasn't easy to discover what caused this). So keep an eye on the proxy policy when you call home. I'm sure Max would have much other good advice on interesting data to collect. My feeling is that those users who consent to collecting _any_ data would likely consent to collecting more data than just active install counts. So you might better want to collect things like host OS, Platform Version, screen resolution alongside. I'm not a lawyer and the rules are different in many countries around the world (with Germany being particularly strict it seems), but since there's precedent for what you're trying to do I'd hope that the must-have legal requirements aren't too hard to figure out. [1] http://www.eclipsecon.org/2013/sessions/google-analytics-eclipse-plugins Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 -----Original Message----- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Igor Fedorenko Sent: Thursday, September 05, 2013 2:15 AM To: Cross project issues Subject: [cross-project-issues-dev] proposal: active eclipse installation count service As you may or may not know, p2 can be configured to report feature or plugin "download stats" to a remote server [1]. As a side note, this reporting is done silently, i.e., without telling the user, and both installations from remote servers and local filesystem are reported. I would like to propose extending this functionality and in addition to initial plugin/feature installation count, provide a way to count active plugin installations on ongoing basis. Here is what I have in mind * All installation counting functionality will be moved to a separate plugin, possibly outside of p2. * There will be workspace preference to enable the counting, it will be on by default. * When the plugin first starts, it will inform the user about the counting via a popup dialog or some other UI means and the user will have a choice to either acknowledge the counting or navigate to corresponding preferences page and disable counting there. * The plugin will introduce new extension point that will allow bundles express their desired to report active installation count. I don't have exact details of the extension point yet, but I thin it should be similar to existing p2.statsURI/download.stats p2 configuration properties. * Active installation count will be reported weekly and will only include information about bundles that have the extension point and were active since last report (hence "active installation count"). * On server-side, active installation count will use existing http://download.eclipse.org/stats/ infrastructure, but we'll probably recommend using different URLs for downloads and active installation stats. I also volunteer to implement this, provided there are no objections to the proposed approach from Eclipse Foundation and somebody from platform committers agrees to help me review and merge the changes. For the reference, I've opened bugzilla enhancement [2] request yesterday. What do you think? [1] http://wiki.eclipse.org/Project_Download_Stats [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=416456 -- Regards, Igor _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
