Categories
Releases

v0.0.4 – Like v0.0.3 but with the rest of my to-do list done.

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.

Categories
Releases

v0.0.3 – A week of work, 2000 lines of code.

The software does pretty much exactly what it did before. Cool, eh?

Sometimes you need to reset in order to move forward. In this case, the problem was a very rushed, hacked coding style by someone who made up the language as they went along, and wrote half of it like they were working in Python.

The new version of the codebase is completely refactored to push the Combadge functionality further away. It’s also been split up so that the nitty-gritty of packet-level interaction has been separated out from the logic model of the Combadge protocol. This makes the combadged itself cleaner and also means that we have one “big and simple” chunk of code to handle the packet bytes, and one “small and complex” chunk of code to structure the conversation. You can think of it as a huge dictionary full of words, and a small grammar manual.

As well, I’ve moved everything to be an ES6 module, which updates some of the design and also gives us stricter checking – which as a bit of a hack, I definitely benefit from.

I still have some small changes to make to the design of the packet classes which I want to do soon, but the major work of the refactor is done – which should mean I can get on with more “novel” changes soon.

Help welcome, you can find v0.0.3 on the Github as per usual.