4 ms·

I can think of only two GUI apps I semi-regularly use that can't fit within those restrictions: VMware Fusion, and Steam. Plugins are a red herring. Some poorl

by nknight 15y ago

I can think of only two GUI apps I semi-regularly use that can't fit within those restrictions: VMware Fusion, and Steam. Plugins are a red herring. Some poorly-designed plugin infrastructures will not be workable, boo-hoo. Valid use cases can be accommodated with proper message passing. Maybe we'll finally get applications that don't crash horribly because of buggy plug-ins?

pavlov 15y ago
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.
- natesm 15y ago
  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.
  - ryannielsen 15y ago
    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.
    - natesm 15y ago
      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?
      - ryannielsen 15y ago
        As far as I know, yes, that is the case. I'm not an app store reviewer, though.
- cageface 15y ago
  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.
  - nknight 15y ago
    "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?
    - beedogs 15y ago
      I think you're misunderstanding what they mean by "realtime".
    - cageface 15y ago
      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.
  - dbattaglia 15y ago
    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).
- nknight 15y ago
  The IPC mechanism is XPC, and my memcpys run at a few thousand megabytes per second, why don't yours?
  - pavlov 15y ago
    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/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html http://developer.apple.com/library/mac/#documentation/MacOSX...
    - ryannielsen 15y ago
      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=3193354 http://news.ycombinator.com/item?id=3193379 http://news.ycombinator.com/item?id=3193379 http://news.ycombinator.com/item?id=3193404 http://news.ycombinator.com/item?id=3193404
- ryannielsen 15y ago
  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.
DrJokepu 15y ago
Xcode, Firefox, Safari, Google Chrome, VLC Player, Dropbox, BBEdit, TextMate, StuffIt, UnRarX. These are all well-known OS X applications, all of them having important features that require being able to open an arbitrary file without user interaction.
- ryannielsen 15y ago
  The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. I'm not certain why the browsers are listed, but they're in the same boat for local files (perhaps opening a file:/// url typed in the address field would be broken, but double clicking a local html file or using their Open… features would still work). User interaction must happen at some point, otherwise the apps have no clue what files to open. Xcode (and BBEdit's and TextMate's project features) and Dropbox are interesting cases. Dropbox can presumably ask for permission once for each directory the user wants to sync. It does, after all, already use a NSOpenPanel when the user asks to change the sync location. It remains an open question whether it can permanently persist that user-granted exception indefinitely. [1] Xcode is special because opening a project will be a user-specific action, but then each referenced file will somehow need to be opened. There is no solution I'm aware of for that use case. If you're a developer in a similar boat, I strongly suggest filing a radar explaining how your app is broken by the lack of such a solution. I bet the BareBones crew is already working their WWDR contacts, making their needs clear... [1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-and-file-references.html#308916 http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...
  - jbk 15y ago
    > The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. You open a playlist of files or a video file with linked subtitles, then you need to be able to open another file, that can be arbitrary located.
  - DrJokepu 15y ago

by nknight 15y ago

pavlov 15y ago

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.

natesm 15y ago
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.
- ryannielsen 15y ago
  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.
  - natesm 15y ago
    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?
    - ryannielsen 15y ago
      As far as I know, yes, that is the case. I'm not an app store reviewer, though.
cageface 15y ago
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.
- nknight 15y ago
  "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?
  - beedogs 15y ago
    I think you're misunderstanding what they mean by "realtime".
  - cageface 15y ago
    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.
- dbattaglia 15y ago
  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).
nknight 15y ago
The IPC mechanism is XPC, and my memcpys run at a few thousand megabytes per second, why don't yours?
- pavlov 15y ago
  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/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html http://developer.apple.com/library/mac/#documentation/MacOSX...
  - ryannielsen 15y ago
    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=3193354 http://news.ycombinator.com/item?id=3193379 http://news.ycombinator.com/item?id=3193379 http://news.ycombinator.com/item?id=3193404 http://news.ycombinator.com/item?id=3193404
ryannielsen 15y ago
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.

DrJokepu 15y ago

Xcode, Firefox, Safari, Google Chrome, VLC Player, Dropbox, BBEdit, TextMate, StuffIt, UnRarX. These are all well-known OS X applications, all of them having important features that require being able to open an arbitrary file without user interaction.

ryannielsen 15y ago
The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. I'm not certain why the browsers are listed, but they're in the same boat for local files (perhaps opening a file:/// url typed in the address field would be broken, but double clicking a local html file or using their Open… features would still work). User interaction must happen at some point, otherwise the apps have no clue what files to open. Xcode (and BBEdit's and TextMate's project features) and Dropbox are interesting cases. Dropbox can presumably ask for permission once for each directory the user wants to sync. It does, after all, already use a NSOpenPanel when the user asks to change the sync location. It remains an open question whether it can permanently persist that user-granted exception indefinitely. [1] Xcode is special because opening a project will be a user-specific action, but then each referenced file will somehow need to be opened. There is no solution I'm aware of for that use case. If you're a developer in a similar boat, I strongly suggest filing a radar explaining how your app is broken by the lack of such a solution. I bet the BareBones crew is already working their WWDR contacts, making their needs clear... [1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-and-file-references.html#308916 http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...
- jbk 15y ago
  > The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. You open a playlist of files or a video file with linked subtitles, then you need to be able to open another file, that can be arbitrary located.
- DrJokepu 15y ago