Closed jakaplan closed 2 years ago
@amomchilov would appreciate your feedback on this, both at a code level as well as the overall approach. I think this is reasonable design, but I'm not entirely convinced it's the best one.
So far we called the incoming thing a "message", not a "request", is that right? So perhaps
XPCMessageContext
would make sense in that context (heh).
Terminology is hard! My intention, which I may not have consistently succeeded at, is that "message" refers to the object being sent via the client to the server. This means there are two route types which have no message, but they still result in a server handler being called. Hence I chose "request" instead of "message", but it's true this introduces yet another noun. I also considered XPCClientContext
as it's describing the client, but I thought that was somewhat confusing and could be confused as something that is accessible on/to the client.
is that "message" refers to the object being sent via the client to the server. This means there are two route types which have no message, but they still result in a server handler being called.
I think it would make more sense if the terminology such that all 4 route types send a request, and some of them have a message attached.
Then XPCRequestContext
would make perfect sense as a name for this
The core addition here is the introduction of the entirely optional
XPCRequestContext
which has static properties that are accessible within the execution context of a closure called byXPCServer
.The motivation behind this PR is that there are times where I need to differ the behavior of the server based on the caller. Since I trust all of my clients I could have them explicitly provide this information, but it seemed more robust to have this be determined server side.
The design is a bit "magic" so I'm torn on it. I considered three different approaches and ultimately settled on this one. The other two considered were:
XPCRequestContext
as a parameter.XPCRequestContext
as a parameter.Approach 1 felt far too heavy handed as I don't think the average user of SecureXPC will need to make use of
XPCRequestContext
. Approach 2 would require doubling the number of handler registration functions from 8 to 16 along with all of the associated boiler plate. Additionally it'd makeXPCRequestContext
more prominent in the API and that's undesirable as again I think it'll be needed in a small minority of cases.