Some ideas for the future

[fpseverino]

Hi everyone, I would like to hear your opinion about some ideas I have for the future of this package.

First of all, as we discussed in Discord, I was thinking of changing its name into something like "vapor-community/wallet" (vapor-wallet is already taken), for multiple reasons:

• Right now PassKit is strongly tied to Vapor, and usually, when we use "Kit" in a package name, it means that it's an indipendent library
• Nowadays PassKit doesn't deal only with Apple Wallet passes, but also with Apple Wallet orders, and maybe in the future with Google Wallet passes too
• PassKit is the name of the Apple framework and also of a company that deals with digital passes, so it could be confusing

Beside the name change:

1. I would like to separate this package into several:
   • swift-wallet: A package that depends only on swift-crypto, swift-certificates and Zip that handles only the signing and building of passes and orders. For this I would like to wait for Encrypted PEM keys apple/swift-crypto#264 to be solved, as that would make this package available on all platforms and not exclusively on macOS and Linux.
   • fluent-wallet: A package that depends only on FluentKit and holds all models related to passes and orders, so that they can be used with every web framework that supports Fluent (AKA Vapor and Hummingbird).
   • Last but not least this package and a future Hummingbird one that will depend on swift-wallet and fluent-wallet and will handle API routes and auth middleware. When the SSWG HTTP server and middleware library will come out we could consider creating another common package, making the Vapor and Hummingbird providers even thinner.
2. The APNSClient has to be initialized with TLS using the same certs used to sign passes/orders. Right now its lifecycle is handled by vapor/apns, but to make it independent we have to use APNSwift directly and manually handle its lifecycle. I was thinking of initializing the APNSClient with an EventLoopGroup provided by the web framework, and then adding a shutdown method to PassesService/OrdersService so that the Vapor and Hummingbird drivers can shut it down appropriately.
3. I was thinking of getting rid of the delegate pattern used in the services. Users could pass to the service initializer all the parameters and closures needed, instead of a delegate with properties and functions. ✅ Done!
4. Assuming we get rid of the Application and delegate properties, could PassesServiceCustom/OrdersServiceCustom become a struct instead of a class?

Please let me know what do you think about all of this!

[wibed]

wouldnt it be more usefull to have passkit repo take care of the package and hand the repo once it is done to passkit?

once it changes changes domains from passkit to something else its becomes a technical overhead to maintain as divergence is guaranteed.