[Feature] Add additional hooks to better handle faulty device-implementations

[benbender]

This is kind of a followup-request to #167. This lib is really superb and of great help while implementing UPNP/DLNA for devices. Thank you for that!

What I'm missing though, is the option to hook into the handling of data sent from a device to be able to patch faulty implementations on the fly. I can do that easily for notifications via the on_event-hook, but for, f.e., action-responses or xml-specs of a device, I'm a bit lost.

I would love to have something like an "on_action_response"- or a "on_recieve_spec"-hook (naming tbd).

IMHO those additions would greatly improve this lib without any breaking change. What do you think?

And last, but not least: Thanks again for your work for the community! <3

[StevenLooman]

Thank you for your kind and encouraging words @benbender!

Adding hooks is a great idea, thank you for this suggestion! There are many devices which indeed require some sort of special handling/pre-processing. Initially I was hoping to handle all these cases within the library itself (hence the non_strict option in the UpnpFactory, for example), but this can never be satisfactory for all devices. I.e., see #201 where the namespace alias definitions are missing spaces between definitions.

I hope to work on this somewhere the comings weeks, but I can't promise it'll be done in time. Feel free to open a PR if you want this faster.

[benbender]

Thank you!

Just to give some context: I'm playing with the DLNA-implementation of Linkplay-devices. They are basically producing chipsets for other manufacturers to implement into their devices to handle audio-streaming, multiroom-grouping, etc.

DLNA is part of Linkplay's firmware and they have structured vendor-implementation in a way so that every device gets a "project" assigned and firmware-updates are specific to those projects. Often enough newer firmware-versions aren't available even if the underlying chipset got firmware-updates. It's virtually impossible to fix this from the outside and so the only way will be patching (many) glitches on the client-side.

Some problems I'm seeing on those devices:

• Action-specs are sometimes invalid or incorrect. (patch via "on_recieve_spec". No easy option atm I would be aware of.)
• Broken XML on notifications. (Can already be patched via on_event-hook)
• Broken XML on action-responses. (I could implement fixes by subclassing and hooking into the requester. A nicer API to handle those cases would be appreciated).

If my time allows me to, I'll also will look into a PR. No promises though.

[StevenLooman]

What kind of granularity do you require? Do you need a hook per action, or one hook for all actions? On the one hand I'd like to be complete, but I also don't want to include functionality which will never be used. Of course, a hook for actions calls should include the action itself, such that one can differentiate there.

Next to the pre-processing of responses, I can also imagine one would like to have the ability to pre-process the requests.

[benbender]

For my usecase one hook for all actions would be enough. Maybe just include the method in the parameters of the hook so the user can decide if he_she needs more granularity…?

Regarding hooking requests: I also could see those needs even if I don't have those.

[StevenLooman]

Can you give some feedback on #233? E.g., does it fit your needs, and/or do you think any hooks should be done differently?

[benbender]

I'm on vacation until mid of next week – I'll take a closer look when I'm back, but on first glance your approach seems like even more than what I had in mind! :)

[StevenLooman]

Take your time! I'm planning to include these into the next home assistant beta (around the 25th?), so there is plenty of time.

I wanted to be sure that most foreseeable cases could be covered using these hooks. I've included some refactoring of the requests/responses (the HttpRequest/HttpResponse classes) for a bit more clarity. I'm sure anybody who has worked with aiohttp (or requests, or urllib) would understand the Tuples, but this seems more clear.

[StevenLooman]

Were you able to take a look, @benbender?

[benbender]

Yeah, sorry, I had a look and I'm impressed and it's more than I had in mind initially. I did not find time to port my stuff over yet, but from my POV it is good to go. LGTM!

[StevenLooman]

The next beta Home Assistant is planned on the 26th. I plan to get everthing ready around the 25th. I'll keep the PR open until then. If you find time to see if it fits your needs, then great. If not, I'll merge anyway. Anything that needs to change/be fixed can be done in a future release.

[benbender]

Sounds good to me. Thanks again! <3

[StevenLooman]

I am going to create a release now. As said before, if anything turns up we'll create a new release.