Hi, Adam! On Sep 09, Adam M. Dutko wrote: > > So, "Phone Home" or "MySQL feedback daemon" or "better name wanted" > > feature. > > Maybe call it "Butler" ??? Just a thought...
:) Why? > > Not unlike the Uptimes Project or Debian Popularity Contest. > > Opt-in only with an easy disable option after opting in... correct? Of course. Sorry, I didn't make it clear enough - the first email was only about questions, unclear moments in this task. Whether it should be opt-in is not one of them :) > > The complete specs will be here: > > http://askmonty.org/worklog/Server-Sprint/?tid=12 > > > I imagine the following ... > > (optionally by user) geographic location > (optionally by user) user information / company name > (optionally by user) Monty Program Ab customer support contract id > > won't be shown to everyone, correct? So maybe a filtered public > versus unfiltered private view? Of course. > > 1. Should that be a MariaDB plugin or a separate executable ? > > > A separate executable would probably be the best for the reasons you > highlight in your first paragraph. The drawbacks are probably covered by > the fact that 1) if a user is having that awful of a time, they are probably > able to step through the executing code or 2) the user probably has a > support contract with a company that can step through the code and debug the > problem. Granted more in depth statistics would be useful, but maybe it > would make sense to have a separate project to create a loadable module that > would be "more invasive." This tool seems to be oriented towards usage and > "usage related" data, not necessarily troubleshooting/fixing. Right. > > 2. How to send the data. > > > I imagine if the code is generated with this in mind it should be easy > to switch out the "transport" (read transmission method) layer at a > later time. Unless the person coding it really ties the data > formatting and submission process to the protocol. Right. > 3. Auditing. > > > I think the proxy idea, as well as the "wget mode" are great ideas. > If the user isn't paranoid and doesn't want to "sniff traffic" one > could also provide a log of all activities and a separate log for all > messages. Yes. I was trying to find something convincing for paranoid users (like me :). Normal users can just look in the log. > > 4. What to report. > > > > hardware: CPU, RAM > > maybe disk speeds? and type? (SATA vs SAS vs IDE) Good idea. Indeed, it's important. And to know if it's SSD or not. > > OS (linux distribution, kernel) > > any libraries? I don't know. As you said it's not to troubleshoot, it's to steer development. I don't know if we may want to optimize for a specific version of a specific library. And if yes - for what library? > > number of databases, max/avg number of tables in a database, > > > the slightly insane might also run multiple instances on a single > machine, so what about checking for other installations? Right. > Just a few thoughts, hopefully they're not distracting or useless. Not at all! Thanks for sharing them. Regards, Sergei _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp