• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sandboxing die.die.die
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sandboxing die.die.die


  • Subject: Re: Sandboxing die.die.die
  • From: Mike Abdullah <email@hidden>
  • Date: Wed, 29 Aug 2012 17:17:17 +0100

On 26 Aug 2012, at 03:02, Graham Cox <email@hidden> wrote:

>
> On 25/08/2012, at 8:14 PM, Mike Abdullah <email@hidden> wrote:
>
>> I had a funny feeling you were going to point the finger at us ;-)
>> Checked out the code, and I can assure you, iMedia is doing this:
>>
>> NSURL* url = [NSURL URLWithString:library];
>> NSString* path = [url path];
>>
>> Where library is a string retrieved from the prefs to note where a media library lives. I continue to be pretty sure no path-based APIs accept URL strings.
>
>
> Well.....
>
> This code was based on a very old version of the iMedia code, probably from 2008 or 9. It was certainly heavily modified when I adapted it to my own structures, but this part I kept intact. In fact, it still retains remnants of a workaround for some other Cocoa bug along with the comments pertaining to it, which is why I know I never altered it. Perhaps the behaviour just happened to work... or perhaps back then Apple were not storing a URL in the prefs but a path?

The latter seems more likely. The thing is this:

file://localhost/example.png

is a perfectly valid relative path, going:

file/		>	localhost	>	example.png

(if you were browsing in the Finder)
>
> It's very probable that it got changed later - I haven't checked to see what the current version does. Presumably, it was updated to use NSURL at some point, but the version I used was path-based.
>
> I hadn't realised that you were associated with Karelia. I wasn't pointing the finger, just trying to understand what the issue was. I accept that in porting the code Karelia no longer have any responsibility for it. What have been your experiences with sandboxing the iMedia browser?

No worries; the "finger-pointing" was meant mostly in jest. We're getting there on sandboxing it. Mostly not tooooo painful, but held up by a bookmarks bug at present.

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Sandboxing die.die.die
      • From: Alex Zavatone <email@hidden>
References: 
 >Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Jens Alfke <email@hidden>)
 >Re: Sandboxing die.die.die (From: Kyle Sluder <email@hidden>)
 >Re: Sandboxing die.die.die (From: Alex Zavatone <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Greg Parker <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Mike Abdullah <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)
 >Re: Sandboxing die.die.die (From: Mike Abdullah <email@hidden>)
 >Re: Sandboxing die.die.die (From: Graham Cox <email@hidden>)

  • Prev by Date: App phases + appropriate phase icon badges.
  • Next by Date: [Q] Cocoa Binding for filters applied to CALayer
  • Previous by thread: Re: Sandboxing die.die.die
  • Next by thread: Re: Sandboxing die.die.die
  • Index(es):
    • Date
    • Thread