Thanks for the replies - just got them now as my MobileMe email went
offline for some reason last night...
I noticed that there is some useful info relating to this topic in
the
documentation on Agents and Daemons at
http://developer.apple.com/technotes/tn2005/tn2083.html#SECLIVINGDANGEROUSLY
It does say that AppKit is not daemon-safe, but my testing suggests
that if
(as suggested in the technote) you avoid sensitive methods it
should be ok
(more info would be welcome).
I'm curious as to whether you really read the thing....
I did, I did! (really)
The fact that some discussion of possible issues *is* provided came of
as sort of a tacit approval that in some cases this approach might be
appropriate.
To me it comes down to what *methods* you expect to work... I
certainly wouldn't expect to be able to instantiate an
NSDocumentController and create and manage documents with it in an
environment with no window server. However if my NSDocument subclass
contains a set of ivars (none of which use AppKit classes) that
constitute a useful data model and implements file IO routines that do
not, in any way, depend on the window server, document controller, or
any AppKit classes, it seems reasonable to expect that this subset of
functionality could be used even on a headless node. I can see how
image decompression routines might be fragile, but the usage case I'm
describing is a little different.
One obvious alternative is to create a 'Data Object' class that has no
AppKit dependencies and stash it as an instance variable in a 'thin'
NSDocument subclass that just supports tasks relating to a real
document-based app in a window server environment. To make my app
work, I need two layers of subclass for my documents (a general
NSDocument subclass and several subclasses of this for specific data
types) so it's a bit more tricky. I'd need to have a data object
class hierarchy and a parallel document hierarchy.
If multiple inheritance was supported in Objective-C, it would be a
bit simpler as I could create parent classes for data document objects
and then multiply inherit the required parent classes in the document-
base app (or just use the Foundation-based data object classes in
headless situations). I suppose the alternative described above is
one of the standard workarounds for multiple inheritance in Obj-C.
So the appropriate question to have asked may well be "what class
structure will work well to factor out data model and NSDocument
functionality so that the data model can be safely used in a headless
context". Keep in mind that the only posts I could find on this were
ones suggesting workarounds for use of NSImage, with the caveats noted
above. Now, the consensus I'm hearing is "don't do it" , which will
help me justify the (slightly) increased complexity required for this.
Rick
"A routine might behave differently depending on its input parameters.
For example, an image decompression routine might work for some types
of images and fail for others."
"The behavior of any given framework, and the routines within that
framework, can change from release-to-release."
In other words, you're playing with fire in a gasoline-soaked shed.
Just because you haven't been burned horribly *yet* doesn't mean you
won't be.
AppKit requires a window server connection, full stop. To the extent
that it functions without one, this behavior is unsupported,
unreliable, and highly risky. Don't do it.
In case you didn't know, having a window server connection isn't the
same as being a GUI app, however. You just need to be able to connect
to it. Realistically, this means either having a user who's logged in
to the GUI and always running as that user, or running as root and not
logging in or out.
And lastly, as far as I know you must initialize NSApplication before
touching AppKit in any other way. Like the window server requirement,
you may be able to get away without doing it sometimes but you should
never rely on it.
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/rickhoge1%40mac.com
This email sent to [EMAIL PROTECTED]
(43092.6825)
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
