Re: AudioFile.h and FSRef??
Re: AudioFile.h and FSRef??
- Subject: Re: AudioFile.h and FSRef??
- From: Herbie Robinson <email@hidden>
- Date: Thu, 19 Sep 2002 18:57:42 -0400
It would be nice if there were umbrella frameworks that pulled in
non-UI portions (things like Carbon file services) without all the UI
support. All those extra headers must slow down compiles something
wicked...
The other thing to point out about the Carbon file system UI is that
is allows for asynchronous I/O. AFIK, nothing else does.... This
means that a multi-tracking application can do all the disk I/O from
one thread.
You're trying hard to stay away from Carbon but if you're using
Cocoa you're already failing and you may not know it. :-)
Cocoa sits on top of the same services as Carbon
(ApplicationServices/CoreServices/etc.) and thus has automatic
access to things like the FSRef-based file manager APIs. It's
already linked in and loaded so it's no skin off your nose to use
them. In addition, the Cocoa event model is driven by the Carbon
Event system so really the two are quite intermingled. Given that,
avoiding one or the other is kind of silly -- use the best features
of both worlds and you'll really be better off. In fact, Jaguar
goes a long way in letting you mix Cocoa and Carbon things as much
as you want.
The CoreAudio team (of which I am _not_ a part so don't confuse what
I say with official team statements) still does significant work on
9 for QuickTime so it's fairly natural for them to use APIs that
exist on 9 and X. Besides, the FSRef APIs are pretty feature rich
and might have more features than you think -- give 'em a look and
maybe they won't seem so evil. In case you don't know, one of the
coolest features of FSRefs is that the user can move a file on you
while you're working on it and you won't know the difference. Try
that with a path-based API!
stephen
On Wednesday, September 18, 2002, at 04:06 PM,
email@hidden wrote:
Hello,
I was looking at the AudioFile.h routines and wondered why FSRef
types are being used. I am confused as to why it appears that
Carbon is *required* for this particular OS X development,
especially since it was announced to be an easy porting solution.
In addition, it seems quite a small thing to have added support for
Cocoa or UNIX types in these calls.
I've been staying away from Carbon on purpose so unless there's
some workaround I think I'll wait until I can use them with Cocoa
or UNIX!
Thanks.
-- John
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.