Generally I'm a fan of code rather than config, as it's easier to debug & follow, but the complexity in making this work with the restrictions could remove a lot of those benefits. We need a series of use-cases, both common & exotic. The champions of "config" need to show (with code) that these use-cases can be met, or justify why it isn't a big deal that particular cases can't be met. The champions of "execution" (which is a great name for a wrestling tag-team) need to do the same, including detailing when the code executes. Ignore the sandboxing for now. This should show: * If "config" is viable without large amounts of complexity & meta-language. * If "execution" runs at a time that presents a security issue (I suspect it does). * If fixing the security issues of "execution" also prevent use-cases. As in, if some use-cases need network access, then that requirement clashes with the security requirements. After this, if "execution" looks like the best solution, we can look at the examples and pick a sandboxing method. Which is best depends on what kind of event loop and API access it needs. But we need use-cases and code examples before we tackle that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-275445099
Received on Thursday, 26 January 2017 17:02:40 UTC