On Wednesday 09 August 2006 11:38, Kevin Ottens said: > > ------------------------------------------------------------------------- > >- > > > > + enum Capabilities { WEP = 0x1, WPA = 0x2, WPA2 = 0x4, PSK = 0x8, > > IEEE8021X = 0x10, WEP40 = 0x20, WEP104 = 0x40, TKIP = 0x80, CCMP = 0x100 > > }; [...] > > Added a comment for this one. It can probably get simplified a lot (or > simply disappear) thanks to the Encryption classes. It also addresses > Christopher's comment regarding the fact that it's pretty much tied to > NetworkManager, and I'd dislike to have something that backend specific in > the libs.
I am unsure what to do here. NM returns a set of capabilities describing what the network is capable of, but I'm not sure how it obtains these. It's not inconceivable that a network supports more than one authentification protocol so I would like to keep the enum. The other problem I have is that I currently use Encryption mainly to pass auth credentials for a given system to NM, not descriptively. But a network could contain a list of supportedEncryptions() instead of these capabilities... > > ------------------------------------------------------------------------- > >- > > > > + /** > > + * List of access points making up the network, > > + * or ad hoc network nodes > > + */ > > + virtual MacAddressList bssList() const; > > > > Um. This list is inherently incomplete, and thereby worthless. You can > > only add those MACs that you _see_ belonging to the same network. There > > may well be other APs that make up the same network but your client can > > not see. Same goes for Ad-Hoc, here this is commonly called the "hidden > > station problem". I'd suggest to just drop this function. > > Well, I think you missed the point here (hence why I ignored your comment). > It's here to allow us to determine that two networks with the same ESSID > but different APs are probably different (think about the "netgear" SSID). > Two networks (same ssid, different aps) could then be merged if we know > (for example we asked the user) that they're really the same network. Right. > > ------------------------------------------------------------------------- > >- > > > > + signals: > > + virtual void signalStrengthChanged( int ); > > > > Fine, just keep in mind that the strength reported by the card is _almost > > never_ constant, even if you don't move. So this signal will basically > > almost always be emitted when you poll the device info. > > Yep and that's fine IMHO. I'm against simplification of this, although the signal is frequently updated and its value is basically bullshit anyway, it should be left to the Solid-using app to determine how to handle the signal and its value. > > ------------------------------------------------------------------------- > >- > > > > I didn't see outOfRange() in the diff. If it's still in the code, see my > > remarks on its reliability. > > No it's not there anymore. > > > Having it in the repository would be great! > > I'd like to commit it soon, the problem is that the Encryption and > NetworkManager classes are missing. So maybe it'd be nice to wait for Will > first. Back from holidays and working on it again. > Sure! <mental_note>Bring cookies for Stefan.</mental_note> > That said you know that it'll probably be easier to find beer than cookies > in Dublin. ;-) Dublin has just as many coffee/cookie/muffin shops as any other city outside of north Korea, I'm sure you'll be able to find some. Will _______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel