Designing XPCAnonymousServer.start()

[amomchilov]

XPCAnonymousServer can't fulfill the existing semantives of func start() -> Never.

I need some ideas for how to design this API, for #24.

Here's my observations of the existing usages:

1. XPCMachService
   • xpc_connection_resume is called from start() calls
   • start() then also calls dispatchMain, which blocks.
2. XPCClientService
   • start() calls xpc_main, which blocks.
3. XPCAnonymousServer (in the way it looks like in Add support for anonymous connections #24 right now)
   • xpc_connection_resume is called in the initializer. This seems out of place, I think this should be lazily deferred.
     • I would have called xpc_connection_resume from start() if I could, if it wasn't Never() returning.

I like the idea that any kind of server requires a server.start(), but it looks like there are conflicting requirements. It has to be blocking for XPCClientService, it should probably be blocking for XPCMachService (though doesn't strictly need to be), and it shouldn't be blocking for XPCAnonymousServer.

I guess we need to split off two separate methods? If so, one or the other will have a fatalError() implementation, which is usually an indication of a poorly designed class hierarchy.

Got ideas?

[jakaplan]

Edit: The below is worth considering, but I think #30 is the most promising approach I've come up with.

---

I'm assuming XPCMachService -> XPCMachServer and XPCClientService -> XPCServiceServer, let me know if that's not the case.

Here are some ideas, will keep brainstorming. Take these more as inspiration then as fully thought through ideas.

Behavior differs, start() has no return type, fixed behavior

This is the easiest, but least consistent, way to address this. Having a return type of Never is essentially a courtesy, not actually a true requirement. The awkwardness of this that the behavior would be defined by the API and differ.

Behavior specified, start(...) has no return type, & error if not possible

An improvement over the above would be that start(...) now takes in an enum or boolean to specify whether to dispatch the main thread. In the case of an XPCServiceServer we'd throw an error. Alternatively this could be two separate functions and only the non-blocking one would need to throw an error.

Behavior specified, start(...) has no return type, ignore value if not specified

An alternative to the above is that when a value is passed to an XPCServiceServer that can't be honored because starting must block, it's just ignored and this behavior is documented.

"Start type" returned along with server

While this works, it seems pretty odd for Swift so I can't say I like it. But sharing it in case it provides good inspiration. When calling one of the factory methods return a tuple including both the server and a "start type" which must be passed into the start function. An oversimplified version of this could look something like:

public struct StartType<T> { fileprivate init() { } }
public static let StartAndContinue = StartType<Void>()
public static let StartAndBlock = StartType<Never>()

public func start<T>(startType: StartType<T>) throws -> T {
    if T.self == Void.self {
        return startAndReturn() as! T
    } else if T.self == Never.self {
        startAndNeverReturn()
    } else {
        fatalError("should not be possible")
    }
}

private func startAndReturn() { fatalError("Abstract Method") }
private func startAndNeverReturn() -> Never { fatalError("Abstract Method") }

If we were actually to go down this path, it probably makes sense for each subclass to have an implementation like this and not for there to be these two abstract functions.

Inlined route registration, started automatically

Instead of requesting a server, registering routes, and then starting it - what if this was all one step? From an API user perspective this would look something like:

try XPCServer.startForThisXPCService { serverConfig in
    serverConfig.registerRoute(...) // actual call details elided
}

Or for an anonymous server:

let server = XPCServer.makeForAnonymous { serverConfig in
    serverConfig.registerRoute(...) // actual call details elided
}

So we'd add a type like XPCServerConfig (probably nested inside of XPCServer) which a user can't directly create but an instance of is returned as the serverConfig instance above. Then XPCServer itself wouldn't have any registerRoute(...) functions. Basically this is more extensively embracing the use of the factory pattern.

However, this means that in cases where we can't (or choose not to) return because the main thread has been dispatched there won't actually be an API user accessible server instance at all. Is there a use case where one would want access to the endpoint for a named (non-anonymous) XPC server? Because this approach would make accessing that endpoint impossible (without additional work to expose it via other means).

Pass in registration, started automatically

It'd be similar to the above but instead API users would explicitly construct an instance of XPCServerConfig and pass it into one of the factory methods. This is more convenient for the case where different server types could be constructed, but otherwise is slightly less elegant.

Expose two "types" of servers

Instead of just returning XPCServer we could return something like XPCReturningServer and XPCNonReturningServer (unlikely to be actually good names) and each of those types define different start() functions.

Expose actual underlying server types

Instead of hiding the subclasses, actually expose them and have start() functions defined at that level.

[jakaplan]

All of the above have varying degrees of merit, but I think #30 is more promising.