Remember those “small changes” I said I wanted to do, when I dropped v0.0.3 yesterday? Well, they took less time than I expected them to. Three things changed today.
API Consistency
One thing I always hate about defining functions is the often arbitrarily pre-ordered list of parameters. It’s an awful way to create a syntax. So, I’ve replaced that in the Packet class constructors with a cleaner (MAC, {kwargs}) set-up. The kwargs will still vary between Packet types, but the order is now flexible – and default values can still be(and have been) set.
MAC stays separate, because it’s the only required value for every type of packet – and I wanted to make the importance of the value clear.
Now With More BSSID
One of the first features I wanted to include from the OEM Agent is the ability to locate a badge. In Star Trek, this is a pivotal plot device in many episodes; allowing crews to discover that people are missing, to transport to and from locations without complex co-ordinate explanation (or, the interesting-but-weird RFID bodymod used in Stargate) and to recognise when people are misbehaving or in danger. Of course in a typical home environment this is of absolutely no value – since the location will always be “somewhere near the only access point in the building”. But I can see use-cases at hackerspaces and conferences:
“Computer. Locate Gerda from the Club-Mate Distribution Team.”
“Gerda Hackerbrau is near ‘FPS Tournament Pavilion 3’.”
In Logfiles Near You
Of course, right now – there’s nowhere to actually use this data. We have no way to link BSSID’s with locations or AP’s, nor do we have an interface for querying this information if we did; other than the currently-stubbed “Info: Location” page available from the Combadge display.
What we do have is a simple console logging mechanism, and as of now; that has an appended string produced by a PacketClass.summary() function – which returns the key data for each type of packet. Though now writing this I realise posting the “Packet not complete” message in five different subclasses was entirely unnecessary – change for next version, move that to the CombadgePacket superclass!
Still, without actually paying much attention to their exact output, this addition gives similar logging capability to the OEM voice server for the classes that have already been defined, and an easy method to add more later that can be applied to both directions of packet transmission.
Get Yours Today
You can probably guess, but you can pull this down from master as of today, and there’s a tagged release to boot.
Next Steps
Apart from my styling error mentioned above (which would take less time to fix than writing about it did, if not for the pain of editing commits and updating tags) I’m about out of “simple” tasks for the time being. Next up are some big ones:
- Making the agent responsive to the end of a statement, and threading it so it doesn’t lock up the badge thread.
- Creating a multi-badge agent system with an additional port opened and closed as needed.
- Adding some NLP to the agent transcription in order to start interpreting speech into actionable commands.
- Fixing the hang-up code, and adding badge-badge and badge-group calling.
- Opening the Combadge and Agent to the outside world.
- Adding support for Users.
- Adding location to BSSID translation.
- Creating hooks to allow external control of badges, and querying information.
As to which I’ll work on next? I’ll think about it in the morning. Picard out.