Hacker News Reader

Comment by pavlov | Hacker News Reader

What kind of plugin architecture do you propose that doesn't use dynamic loading or standard IPC mechanisms? Your "message passing" is much too vague.

Remember, this needs to be fast enough to accomodate FCP video processing plugins - hundreds of megabytes of data may need to be passed between the host and plugin each second.

View on HN

AudioUnit plugins have strict realtime requirements that won't work with message passing too. If Apple disallows plugins that will be the end of the Mac as a pro audio platform. Not that a lot of plugin developers would mind so much after the insane platform churn at Cupertino in this last decade, but it's hard for me to imagine Apple would go that far.

Exactly... AudioUnits and VST plugins literally must be loaded in-process of the host to be useful at all. As long as vendors aren't forced to use the App store for distribution I don't think anyone in that scene will care much about Apple's changes. In the digital music / VST / DAW scene I think the app store's initial launch amounted to a single "oh well, guess not" blog post on CDM and then everyone moved on. (I'm exaggerating a bit of course).

Apple can't get out of Pro market fast enough. They already killed XServe, they "deprecated" Java, which means no chance in hell anyone will try to host their app server on Mac, and now even develop on Mac, they haven't updated their Pro audio software in almost 5 years, the fiasco with FCP X (complete rejection from actual pro users), and most recent rumor they will kill off Mac Pro as well.

Apple wants to be handheld "post-PC" maker and not a computer company. They don't want anything to do with the pro market, people who actually need to do work with their computers.

They killed XServe because it belonged in a market where Apple was insignificant, they weren't selling any. Java now has to be installed separately like on all other platforms. Logic was last updated in August.

There's some chatter about the Pro line going away too.

http://blogs.computerworld.com/19195/apple_kills_the_mac_pro...

As with all Apple rumors, take it with a bucket of salt, they might announce a new line tomorrow for all you know.

"strict realtime requirements" and Mac OS X (and most other off-the-shelf operating systems) do not mix and never have. Either these applications don't belong on the platform in the first place, or you are misunderstanding their requirements.

It doesn't matter anyway. What is it Apple has done recently to give you the impression that they place great importance on niche markets?

Realtime in this sense means an interrupt-driven thread that must respond in fixed time to prevent audio dropouts which are death in pro audio. Previously Apple has assiduously courted this market with their implementations of CoreAudio and AudioUnits and the purchase of Logic. OS X provides by far the best native support for pro audio apps of any operating system.

Lately all this seems to have fallen pretty far down on their list of priorities though.

I think you're misunderstanding what they mean by "realtime".

Is it possible to install the plugins to `~/Library/Containers/...` instead of the usual location?

Not that loading code is allowed on the App Store anyways, unless you're Apple, of course.

Plugins can exist anywhere. They can be placed into the app's bundle without necessarily breaking its signing seal, they can exist within the app's container if the app has a way of copying them in (e.g. it advertises a file type, like Aperture's ".ApertureExport" bundle, so the user can double click to load the plugin, or it provides an "Install Plugin" feature somewhere), and they can exist anywhere in the user's home dir or system volume (if the app requests an exception to read files from those known locations).

No code loading restrictions are placed on signed and sandboxed apps. Any signed and sandboxed process is free to map in any code, though that code is bound by the parent process's sandbox restrictions.

This is the one I am referring to:

2.16 Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected

So I guess that you can have a plugin system as long as you don't provide an in-app way to download and install them, like Adium does?

As far as I know, yes, that is the case. I'm not an app store reviewer, though.

Signed and sandboxed applications have no code loading restrictions. They're free to map anything into their memory space, though that code will of course be bound by the same entitlement restrictions as the loading process.

The IPC mechanism is XPC, and my memcpys run at a few thousand megabytes per second, why don't yours?

XPC services must be located within the host app's bundle [1]. They must be appropriately code-signed. How do you propose to use this mechanism for 3rd party plugins?

[1] http://developer.apple.com/library/mac/#documentation/MacOSX...

As I've pointed out elsewhere in these comments, XPC isn't required for supporting plugins in a sandboxed application, and it's possible for plugins to exist within a signed and sandboxed app's bundle:

http://news.ycombinator.com/item?id=3193354

http://news.ycombinator.com/item?id=3193379

http://news.ycombinator.com/item?id=3193404

Reply on news.ycombinator.com