search

trilemma-dev / SecureXPC

A simple and secure XPC framework for Swift
MIT License
75 stars 15 forks source link

Allows for async functions/closures to be registered as routes #64

Closed jakaplan closed 2 years ago

jakaplan commented 2 years ago

Adds tests to match

jakaplan commented 2 years ago

@amomchilov For your review. I dislike how much code duplication this introduces, but I couldn't figure out a way to reduce it due to the cascading nature of async.

jakaplan commented 2 years ago

Until then, could you help me understand when a callback should be async?

When the API user wants to create a callback which uses async functions within it, which will be an increasing percentage of functions over time. Without this the caller can't have any route with a reply (or one they want an error to be propagated back from) use async functions because wrapping the code in a Task won't allow for the return value (or thrown error) to be returned.

jakaplan commented 2 years ago

A realistic example could be an XPC service with a route provided a URL to a PDF. The service needs to download and then parse the PDF to extract some data. PDFs are a notorious exploit vector, so breaking out this component into an XPC service would be prudent. Using async functions to perform the download would be easiest. And there very well could be async functions involved in the data extraction (ex. running ML inference over it to extract text embedded in images).

amomchilov commented 2 years ago

When the API user wants to create a callback which uses async functions within it, which will be an increasing percentage of functions over time. Without this the caller can't have any route with a reply (or one they want an error to be propagated back from) use async functions because wrapping the code in a Task won't allow for the return value (or thrown error) to be returned.

Ah yes, that makes perfect sense, thanks for the explanation