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 two to make it work with other frameworks (e.g. Hummingbird). Do you think we should keep this as the Vapor specific package, renaming it "vapor-community/wallet" (vapor-wallet is already taken) and moving all the basic logic to a new "WalletKit" repo, or the other way around, removing from here all the Vapor specific code and then creating a new Vapor driver in another repo? Either way, should we copy the existing license/copyright in both projects?
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.
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.