Originally Posted by IQgryn
Another problem is it is hard to match which player you inspected with the notification. It would be much nicer to be able to inspect by name, and have that returned as the inspect ID, or something similar. It would be even better if they did name+requestID.
|
Shared resource makes kittens cry
Goal: let addons scan whatever inspect data is currently available.
Current Challenge: No facility to identify which unit the inspect data belongs to.
It's really awkward having to deal with the Inspect API, knowing that any addon at any time can interfere with your calls. Making a library would only fix half the problem; any other addon could still interfere with the Inspect API, and therefore mess with the entire Inspection library.
I think managing concurrent inspection requests is best accomplished in the root API itself. Not much would have to change: add either serialized requests, and pair "ready" notifications with unique identifiers (for the request or the unit)... or "not ready" events if the inspect API is busy. There just isn't enough transparency in the current implementation to allow either of those things. or, I'm a bad programmer.
It's also a real shame that the data returned from the Inspect API can't be shared between addons. "INSPECT_TALENT_READY" doesn't really help a concurrently running addon. It would know that somebody else is at some state in the inspect workflow...but it can't piggy back and/or use the currently available inspect data out of context; it needs a player GUID or a unitID. That data could be made available in a 3rd party library, or a revamped Inspect API implementation. without the identity data, though, sharing of inspect data results isn't really feasible :3
To Solve: include a unit GUID in the INSPECT_TALENT_READY notification; or, provide a function to query the talent group's owner:
guid = TalentGroupOwner()