Conversation
Signed-off-by: reesericci <me@reeseric.ci>
Signed-off-by: reesericci <me@reeseric.ci>
|
Thanks for looking at this! We will have to be a little more careful to make sure the public API is not changed at all, as extension systems are particularly sensitive to breakage in that way. However, I don't quite yet understand how this implementation adds XPCSession support. Can you help me understand the plan a little better? |
|
It adds an |
|
Ok, yes. What I do not understand yet is how that change helps move towards the goal. In fact, I see you've removed the init I added to try to match the XPCSession stuff that was added. Don't get me wrong, I'm very interested in doing this. I just don't fully see the plan you have for how to get there yet. I'm sorry I'm being so slow... |
|
It kinda doesn't. It just allows for passing/creating XPCSession based handlers to the parts of the library that don't rely on ExtensionKit (which doesn't support XPCSession). |
|
I'm sorry for being so slow here, you've caught me at a bad time. I'm very into addressing this, I just don't see it quite yet. And making public API changes to this library is super painful, because if it is being used, it is itself making up the public API for extension interfaces. So, if things are going to change, I really want to be sure I understand the path so it can be done with as little churn as possible. Can you help me understand exactly what the plan is here? |
This pull request adds basic XPCSession support for the parts of the library reliant on ExtensionFoundation. However, I found out the hard way that ExtensionKit still doesn't support XPCSession, so most of the library is untouched.
All of the new XPCSession support is prefixed with "XPC" as to not break backwards-compatibility.
Related to #2