<div class="gmail_quote">On Sat, Dec 26, 2009 at 1:38 PM, Marcel Holtmann <span dir="ltr">&lt;<a href="mailto:marcel@holtmann.org">marcel@holtmann.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Sam,<br>
<div class="im"><br>
&gt;         &gt; The other thing are the quality and noise properties. Do you<br>
&gt;         still want<br>
&gt;         &gt; these? Or can we just go for a signal property showing the<br>
&gt;         dBm value<br>
&gt;         &gt; like iw scan does. I don&#39;t see any extra value in keeping<br>
&gt;         deprecated<br>
&gt;         &gt; values in the new API.<br>
&gt;<br>
&gt;<br>
&gt;         Please lets get rid of them. One signal strength value that<br>
&gt;         could be<br>
&gt;         trusted to contain some useful data is much better than three<br>
&gt;         with<br>
&gt;         semi-random values no one can figure out.. Quality has never<br>
&gt;         been<br>
&gt;         defined properly and noise is not even a property of a BSS (it<br>
&gt;         is per<br>
&gt;         channel and should not have been mixed with scan results in<br>
&gt;         the first<br>
&gt;         place).<br>
&gt;<br>
&gt;<br>
&gt; I think dropping noise floor is a bad idea unless you add another<br>
&gt; mechanism at the same time to get it (is there a mechanism in the new<br>
&gt; d-bus api?).   The quality parameter has never been useful IMO and<br>
&gt; dropping it would make sense.<br>
<br>
</div>isn&#39;t the new survey API of nl80211 doing exactly this for you?<br></blockquote><div><br></div><div>Who said anything about linux?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
&gt;         &gt; Do you think a &quot;Display&quot; or &quot;Name&quot; property showing the SSID<br>
&gt;         in<br>
&gt;         &gt; converted UTF-8 would be useful. Or should the clients do<br>
&gt;         that<br>
&gt;         &gt; translation?<br>
&gt;<br>
&gt;<br>
&gt;         I would love to have this, but I do agree that it is next to<br>
&gt;         impossible<br>
&gt;         to get this right in all cases.<br>
&gt;<br>
&gt;<br>
&gt; I agree w/ not doing translation in the supplicant.  In my world this<br>
&gt; work is part of the UI and unless we push state down into the<br>
&gt; supplicant it cannot do as good a job.<br>
<br>
</div>What state are you talking about? The concern here is to figure out the<br>
locale the AP is potentially using. Even with a country IE available, it<br>
is not guaranteed that it matches the locale of the SSID, but that might<br>
be as close as it gets when guessing.<br><br></blockquote><div>The state needed to do the localization/translation of the string.   This is not just a locale it&#39;s also all the libraries and related bits.</div><div><br>
</div><div>-Sam</div><div><br></div></div>