Question: Libarary Theory of Operation

[mstovenour]

I'd jump right in and start debugging issue #72 for you but I'm intimidated by the completely revamped library. It took me about 2 months to trace and understand the startup, discovery, message sending, and message reception of python-insteonplm. I'm not looking forward to the same reverse engineering again. By any chance, did you happen to write up even an outline of these tasks in the new library?

[mstovenour]

@teharris1 could you start by outlining the rational for the topics? I clearly see a pattern but I don't understand the intent except for the most basic, obvious uses

[teharris1]

Topics are used by the underlying pubsub module. The pubsub module allows for a publisher/subscriber model (albeit the implementation is really a loosely coupled callback model). I chose this approach because topics are easier to follow when debugging rather than trying to follow callback threads. If you log topics then you just need to find subscribers to those topics. I also felt this was an easier way to keep separation of the layers. Have a look at the architecture:

[mstovenour]

Thanks for that diagram. It is a good start of some class documentation.

I totally get what topics represent generically and how pub/sub works. That's not what I'm asking. I'm asking if you could document the "purpose" of topics you've defined. What I think would help anyone trying to contribute is to have a list of topic hierarchies documented with their purpose. I mean I can create any topic I want right? for any purpose. But I suspect you'd reject a random pull request that seems inconsistent with the topic usage as you've already implemented. I think I'll eventually reverse engineer all the topics but that's a pretty high bar for most people that might try to contribute.

Also I'm myopically focused on topics because, as I've found, they are the foundation of debugging and tracing the code. The logging facility faithfully traces topic publications but it is hard to understand what all that means without many hours reviewing the code.