<br><br><div class="gmail_quote">On 19 March 2012 14:59, Alex Fiestas <span dir="ltr"><<a href="mailto:afiestas@kde.org">afiestas@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This kind of Disk operationsa are not material for SystemSettings, be aware<br>
that System Settings IS NOT like the "Windows control panel", the main<br>
difference is that ours is ONLY for preferences while Windows CP is for system<br>
management as well.<br>
<br>
Said that, I don't think these Disk operations should be done in system<br>
preference but instead in a separate application.<br></blockquote><div><br>I get it.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">Do we have any guarantee that libatasmart API won't change? I don't care on<br></div></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

using udisk/udisk2 but I want we to abstract it in a way that we only have to<br>
care about creating a new backend in case that udisk2 changes its api (I'm<br>
sure we will see udisk3 someday).<br><br><br></blockquote></div>So the best way to go about it would be to modify our existing udisks backend (and the upcoming udisks2 backend) so that they expose SMART atrributes and other relevant udisks dbus methods to the frontend classes ,and then create the application using this new solid API, right? <br>
Of course, I think we still need to investigate if the set of SMART properties/methods available through udisks are sufficient for our purposes.( I'm not sure it provides all properties/functions provided by libatasmart)<br>
<br>As for the need to run SMART tests, I'm finding info on how SMART attributes are updated (besides testing, there's only offline data collection which updates these attributes AFAIK)..<br><br>