>> When a user adds a JPEG/PDF to the document should A) I copy the file into the package using standard file system calls, or B) read the source file as NSData, add it to my model?
Well, you can't do A. You can't really put a file into the document package before save time, because you don't know where that will be, and it would a terrible mistake to modify the original package. What I would try first is to make a place in your data model for an "imported" or "placed" image/file, and just put a URL there. At save time, when you're writing the actual document package, copy the data from this URL into the document. If you need the file contents for display in your UI, you might choose to keep a CGImage or NSImage or CGPDFDocument object in memory too. But there are 2 other considerations:
1. If the user can modify, move or delete the imported file after adding it to the document, you might want to grab its data instead of keeping a URL reference. You can either turn it into NSData, or copy it to a temporary location. The correct behavior here depends on the semantics of your app. If the user expects that they're placing a reference, a URL would do. If they expect they're placing the data, a URL is probably not the right way.
2. If you expect to be able to use memory mapped reads for these files (which, roughly, requires they're on a local file system), you might choose to use memory-mapped NSData objects instead, and forget about the explicit URLs.
But do the most natural thing first, and worry about excessive file-data-copying as a performance issue later.
>> When a user deletes a file from the document package, should I (C) delete the file using standard fs calls and invalidate the (NSFileWrapper*) for it, or (D) just invalidate the file wrapper and assume the file will be deleted when the document is saved?
Again, you can't delete the file, because you shouldn't (and maybe don't have permission to) modify the document until save time. Just delete the file's wrapper, and NSDocument will just not include the file in the saved package. It does the right thing for free!
>> How does saving in place or not saving in place affect the above?
When I was checking the documentation for the previous post, I came across a statement that in-place is needed for the NSDocument file coordination to be enabled. Save in place is more efficient, and can use the system-wide document versioning mechanism that powers the Time-Machine-style "history of time" view of older versions. This versioning also saves only changed file fragments, so it's more space-efficient than keeping multiple versions, too.
When you save in place, File -> Revert to Saved, changes to File -> Revert to Version… .
