[GSoC] Automated Usage Stats Collection
rishiag.iitd at gmail.com
Sun Apr 1 02:45:23 EDT 2012
Thanks for your interest in my application. I would like to answer your
queries as follows:
1. Regarding restrictions, I have following examples in my mind:
(a) No direct access to user's and his contacts' mail ids. If at all, a
plugin requires to collect these stats (let's say a plugin which collects
the level of participation in a group chat), actual ids will be substituted
with dummy markers.
(b) Limited access to chat conversations and keyboard. Actual chat
conversations can't be logged and only keyboard commands (like Alt +F4) can
be logged. This is basically to facilitate debugging while not compromising
The crash reports that I am targeting are mainly from the plugins' crashes.
Also, why I thought grouping of crash reports and filing under the same
ticket will be required is because multiple user's will have same sort of
crashes in a single plugin. Grouping will make it easy for the developer to
prioritize the issues which need to be fixed.
Regarding the account management point, I agree with you that maintaining a
separate account for every developer will be a bit cumbersome. I was
thinking of public-private key approach to do this, where a plugin
developer will share the public key with the logging framework and will use
the private key to access the logs. The reason I included this was so that
the developer can easily track issues related to his/her own plugin. A
simpler solution will be to keep the logs sorted according to the plugin on
I am more interested in providing the logging API rather than usage data
collection part of the project as I think this would be a great value add
to the Pidgin Universe. I'd be happy to provide more clarifications if
On Sun, Apr 1, 2012 at 2:31 AM, Mark Doliner <mark at kingant.net> wrote:
> On Fri, Mar 30, 2012 at 11:47 AM, Rishi Agarwal <rishiag.iitd at gmail.com>
> > The basic idea is to provide a logging interface to plugin
> > developers which they can use in their code for monitoring purposes (with
> > proper restrictions to protect user privacy).
> What sort of restrictions did you have in mind?
> > 3. Add support for crash reports. Maybe, try to file them under already
> > tickets.
> I think crash collection and reporting would be fairly independent
> from usage stat collection and reporting. It's not clear to me if it
> makes sense to lump them together in a single summer of code project.
> Also I don't think it's a good idea for crash reports to be tied to
> already open tickets. I think this would be difficult to implement,
> possibly fragile, and susceptible to false positives. It doesn't seem
> worth the effort.
> > 4. Website to display the stats. Also, every plugin developer can have a
> > separate account on this to view his/her plugin's logs.
> I wonder if it's really necessary to need an account to view this
> information? If the information really is anonymous then I feel like
> it should be safe to make it public. I see difficulties with trying
> to keep the information semi-private, or visible only to the plugin
> author (how would you enforce that the registered user is the plugin
> author? what would stop the plugin author from resharing the
> information or sharing his account?). Plus, account management is
> inconvenient--why require an account if there's no reason for it?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel