Hey all,
Thanks for all the great discussion thus far, and I look forward to lots more discussion in the future.
Do note that we’ve never said that there would be no option to access external processes. What we do need to be careful about are these things:
-
Security and Privacy. A trusted ecosystem is a win for everyone involved – Adobe, customers, and developers alike. The safety and privacy of the user is paramount. Users shouldn’t have to worry whether installing a plugin can harm their machine – intentional or not. Now I understand that we can’t be perfectly secure and accomplish actual work, but security and privacy are things about which we must address, and which we must address carefully. To ignore the potential for abuse or misuse is to misplace the trust of all of our users (yours and ours). Once a user is burned by one plugin, they may elect not to to trust other plugins. That would be disastrous for everyone involved.
Also, we’re not raising security and privacy just because we fear malicious actors in the ecosystem. The truth is that it’s trivial to do bad things by accident. The history of computing is littered by all sorts of apps that in certain edge cases managed to delete all the files on a volume. Making that a little harder to do by accident is not a bad thing.
-
User Experience. How many times have you launched, say, Visual Studio Code or Chrome, or some other app, only to have a million “Helper” processes sucking the life out of your computer? This isn’t a great experience for anyone involved, and we need to think carefully about that. Arbitrary processes that are outside the host’s control make it more difficult to ensure a consistently good user experience. We have to carefully think about how to make it hard for a developer to end up in a bad state where they can’t terminate a process they started, for example. This means thinking very carefully about the API design itself.
-
Cross-platform and OS version capabilities. Yes, not everyone will want to write a plugin that works on every supported platform, but I think it’s pretty amazing that all but two Adobe XD plugins in the Plugin Manager work on both Windows and macOS, and every supported version as well. Obviously this is also possible with a web browser and even Node, but once you start executing external processes, you’re at the mercy of the operating system itself and how the user has configured it. Apple loves to remove common utility functions on a whim, which means you can never quite be sure your external process will actually work. (A slightly different but not unrelated issue is that of spawning your own processes from binaries bundled with the plugin – you know these exist, but you also have to compile them for each platform.)
All that said, the capability of launching external processes has never been off the table. What we’re considering is the best way forward that doesn’t compromise the user’s security or experience. Furthermore, where the current practice is to launch an external process to do something around, say, licensing, we think maybe there’s better ways to accomplish that by providing a better API. What we want to do is to make a world-class API surface that makes it easy to create amazing and compelling experiences for all of our customers. UXP has never been about taking things away. It’s about providing a great API that empowers developers to do amazing things.
Okay, so what is the ability to launch an external process apt to look like? Well, we don’t know yet. We’re thinking about it, and even working up UX ideas about how that might look, and that’s why we value these discussions.
Lastly, it may seem like we’re missing critical APIs that CEP provided, but this is version 1 of UXP. UXP isn’t done growing or maturing. We’ve got lots of ideas planned for it in the future, and we want it to be a vital platform that leads to amazing things, but we also want to make sure that the platform has a stable foundation as well, and that means thinking carefully about every brick we place.