WWDC2001 Session 138

Transcript

Kind: captions Language: en I'm mark Turner on the carbon technology manager in worldwide developer relations corefoundation as the name implies provides a fundamental set of system services that are widely used throughout Mac OS 10 and they're available for your use as well through both carbon and cocoa and any other application running on Mac OS 10 and a subset of these services are also available to Carbon apps on Mac OS 8 and 9 through carbon lib so this morning we're going to get a great overview of some of the services that you might like to take advantage of in corefoundation and to begin with I'd like to introduce Chris Kane from the core foundation team to start off our overview welcome Chris well welcome this session will be an overview of the core foundation framework it's going to explain what it is describe some of the functionality it contains and review some of the general concepts of usage of core foundation I'll begin with an overview corefoundation is a low-level framework within Mac os10 it's used to implement Mac OS 10 and contains functionality that you can also use in your frameworks and applications as Mark said both of the higher-level frameworks cocoa and carbon used core foundation quite quite a bit part of core foundation as Mark said is also available on Mac OS 9 and 8 via carbon Lib this was done to ease porting of carbonized apps to Mac OS 10 and to bring some of the features of core foundation to the libraries and applications on 8 & 9 for similar reasons part of core foundation is also available from Darwin or within Darwin the core foundation API SRC api's on Mac OS 10 through carbon lib they are also available in the language is supported by Carbon lib there are also C++ wrappers for core foundation in Apple's C++ frameworks for Mac OS 10 finally I'll briefly note that core foundation is often simply just called CF and I'll probably slip up during my talk and use that abbreviation myself so it's good for you to know right off the bat now why did I call core foundation a low-level framework well partly that is due to where it sits in the overall organizational structure of Mac OS 10 here we see the usual simplified diagram of the structure of the system frameworks on Mac OS 10 core foundation slips in as part of the core services umbrella frameworks framework but I also called core foundation a low-level framework because it deals with some of the most basic building blocks of your applications and your frameworks these are the data structures that you use to store information in your application core foundation provides several basic opaque data structures that you can use rather than having to write your own and core foundation also provides several higher-level application services which are built upon the basic datatypes and again Apple system applications and system frameworks within Mac OS 10 use these facilities quite extensively one of the key aspects of core foundation is that it does not provide any graphics or media related features in the architecture of Mac OS 10 graphics and fonts and sounds and those sorts of things are introduced in higher-level frameworks frameworks at a higher level than core foundation within that architectural diagram so let's begin by looking at some of those basic data types we start with CF string a data type representing strings of characters strings tend to be one of the most common data structures in an application and in Mac OS 10 CF strings are certainly the most common core foundation data type in use conceptually a CF string is an array of unicode characters however because the implementation is hidden behind the opaque CF string type and its functions a CF string can be smart about how it stores those characters and use 8-bit encodings if possible or do other tricks for performance this takes strings beyond the traditional domain of say a an array of 255 characters as in Pascal in some encoding that is currently in use in the system or in the application by packaging up the characters the length and a fixed encoding in one type use of strings in an application is simplified and this makes things like internationalization easier plus by making the structure and nature of a string more predictable passing and sharing strings among different parts of an application and frameworks is made much simpler CF string has become the way to pass string data between library api's framework api's and applications in Mac OS 10 and it is primarily a primary way in which strings are just simply stored within an application as well and as new api's are introduced they are going to use CF strings as their parameters and return values as well now CF string is an abstract data structure so in addition to the opaque data type there are of course a bunch of functions a bunch of operations on CF strings first of all there are many ways to create a CF string you can create them from a pascal string from a c string you can create them from an array of bytes and an encoding you can also create them from other data if you will like int sand and what have you using formatting functionality similar similar to the c languages printf function there are also several ways to extract the characters of a string and do encoding conversions for example on byte data and converting them to and from strings this is very handy when you're getting information off the internet for example and need to convert that win latin one HTML page into something you can more directly use there are also many other common and useful operations I give two examples here of a pending and concatenation and finding type operations in addition to see a string corefoundation provides a number of other basic datatype abstractions and here are some of them not all of them these are sometimes just simple wrapper objects for simple data types for example CF boolean represents either true or false and that's very straightforward but in most but most of the time these data structures also provide other useful operations as an example there are a few types to represent dates and times provided by core foundation and there are also some operations to work with the Gregorian calendar representation of dates you know years months days hours etc these functions can do things like figure out what day of the week it is or what day what the date will be say 90 days from now and those are just just representative examples of some of the functionalities now some of these types may seem to be really too simple to be useful API but they sometimes come in handy when dealing with collections and as we'll see in a bit many of these are central pieces of the property list mechanism core foundation but for now I'm going to talk about the collection data structures in C F core Foundation a collection is something that groups together other objects and it generally does not matter what the type of those other objects is in the case of the core foundation collections it is most convenient to store other core foundation objects however the operations of the collections with respect to the type of data that they can hold can be configured with callback functions to hold any pointer size values for example you can configure a collection to hold integers the callback functions determine what happens when custom values are added and removed and how they are compared when comparison type operations are applied to a collection the usefulness of these collections is that they can manage the memory for you and I'm going to begin by talking about to the collections CF array and CF dictionary first we have the CF array like an array in the C language the values are kept in order and are retrieved out of the CF array using a zero-based integer index the diagram on the right is showing this mapping from indices to values like unlike a CF array though the values are kept compact in that if you remove an element from the middle of an array the values with higher indices are shifted down one in order to keep the what you might call the index space the indices that you would use to access elements keep those contiguous in addition to using a CF array like an array it is quite common to use them as stacks and queues the other collection I'm going to review today is CF dictionary with a CF array the pointer size values were indexed by integer in a CF dictionary the values are indexed by keys and you can see this in the diagram which are themselves often see other corefoundation objects but can be any pointer sized values in the diagram the strings are being used as the keys if I asked for the value with the name key for example at the top there the dictionary would return me value 1 a CF dictionary is somewhat like a struct in C although you don't want to go and change all your structures in your C code to use CF dictionaries there's a time and a place for CF dictionaries and for Struck's also unlike a CF array the values in the dictionary in any particular order and this is because CF dictionary is based on hashing for fast access performance to the elements and again to reiterate one of the principal values of these collections is that they take care of the memory storage and algorithms for you çf dictionary and CFR rate are both heavily used in the frameworks and applications of Mac OS 10 and though it might surprise you see if dictionary actually tends to be more popular than CF array dictionary just turns out to be a very convenient way to structure data inside of an application one of the ways in which core foundation uses these basic data types and collections together is in property lists a property list is a group of CF objects of these types CF string CF data CF number CF boolean CF date CF array and CF dictionary and only objects of those seven types an additional restriction is that keys of a dictionary in a property list must be CF strings that any dictionary within a property lists so any object or group of objects which satisfies these constraints is a property list for example a single CF string is a property list a single CF number is a property list but more often a property list is a collection or collection of collections for example you might have an array with dictionaries in it and the dictionaries may have dictionaries inside them and they have keys and values which are numbers and boolean's and so on the special thing about property lists this group of objects special type of group is that there is a persistent sometimes called flattened representation which is an xml-based representation so if you have a property list in memory you can easily flatten it oh and write it to a file for example or send it to another application later you can for example if you've written it to a file read the file back in and reproduce the original object graph by using corefoundation to decode the xml representation back into the original objects a file which contains a flattened property list is itself often referred to as a property list and so the term is used for both on disk representations of property list and the in-memory representation the actual objects in use property lists are used extensively in Mac OS 10 as configuration files and for storage of preferences and similar things for example applications in Mac OS 10 are bundles which are represented by CF bundle and inside of a bundle is a property list which is the configuration information for that CF bundle for that application will be discussing CF bundle later in this talk I'm not going to go into it more right now populus are also often simply a useful way of modeling information in an application for example a property list could describe print job and a print server might keep a CF array as a queue of print jobs that need to be serviced here we have just a few of the property lists of a fictitious print job this is not taken from any actual use on Mac OS 10 note that all of the keys in the dictionary are strings the keys are on the left but the values over on the right are a mixture strings and dates and boolean zand numbers the dictionary could also contain values which are arrays or other dictionaries but for space reasons we haven't shown that in this diagram okay let me get that now that you've seen some examples of what core foundation contains let's talk about some of the overriding philosophies concepts and conventions used in core foundation these are the keys to understanding core foundation really because once you understand these you understand the basic operation of all core foundation api's often higher-level api's which are based upon core foundation have also adopted these conventions and picking up a new bit of core foundation api's or those higher-level api's which use the same conventions is thus much simpler and you only have to really concentrate on what those specific api's do what their specific behaviors are and not have to worry about figuring out what the memory management conventions are for example for those api's in particular it is important to understand the memory management strategy and conventions of core foundation because without that understanding you really cannot make proper use of core foundation the general philosophy behind core foundation was to create a high-performance general utility API that could be used as a substrate that is an underlying layer beneath both carbon and cocoa we took many concepts that were already in cocoa and recast them down into a C API which could have wider utility more people could make use of it and at the same time we extended them with some additional features the most important aspect to the design was that the core foundation API should be consistent an API with a high degree of consistency feels like a more unified and cohesive API than one without consistency and it is much simpler to use cohesive API much much more natural again to pick up new API bits of the API when the API is going we also decided to design a peer API around object-oriented models this gave us a way to logically structure the API and means to more easily separate interface from implementation for example nearly all data types and core foundation are opaque and you don't know how they are implemented this also allows ample to make improvements in the implementation over time without being constrained by open data structures however it also means that all core foundation a objects are essentially going to be allocated off the heap in part to achieve the goal of high-performance API we decided to limit the types of validation and checking that the API does limit those to runtime errors thus there's very little checking of programming errors like passing in wrong parameters in the production version of the library which is the one normally that users are running it against we don't have a lot of these any programming error type checks we put these instead in the debug version of the library which uses assertions and other checks to you look for these sorts of programming errors like passing in bad type of object or what have you one of the ways to run against the debug version of the library is explained in the core foundation release notes on the system to ensure consistency we adopted several naming and argument conventions a few of them are listed here not all of them certainly the abstract data types and most higher-level functionality is grouped into classes or modules like in many object-oriented or modular languages we've seen several examples already like CF string and CF number the type of an instance of such a class is named with the class name plus the term ref and that is an opaque reference to an object of that class the operations on that type are functions then that begin with the class name just as the type does and then name the operation so in this example on the slide we have CF string which is the name of the class append format which is the name of the operation another example would be CF array get count which would return the number of elements number of values in the CF array at the time you called that function also in this object-oriented way the first argument to these operations is always the object which is to be operated upon so for example in CF string append format you know that the first argument is going to be a CF string the exception of course is functions which create new objects we call these create functions obviously there's no in that case there's no object for them to operate upon they're creating a new object to other object jointed concepts we adopted in corefoundation to limited extents because of course we're operating in the C language which is not naturally object-oriented our polymorphism and introspection a polymorphic function is one which can operate on many different types of values in corefoundation we have eight functions which can accept references to any type any type of CF object as their parameters and of course in some cases they also return CF types which are CF objects these are used to provide general functionality across all of the core foundation types let's see as an example to find out what type an object is you would use the function CF get type ID the introspection function there in the middle C if get type ID and pass it as an argument a CF object or what you believe to be a CF object and you would compare its return value it returns a code type code you'd compare that return value with the type codes published by every core foundation type in its API so as I said earlier one of the most important things to understand about core foundation is its memory management strategy reference counting is used on all core foundation objects for those of you who don't know what that means in short reference counting is means that each object keeps track of the number of owners that it has that's one way to think about it at least when the number of owners of an object is zero the object can be destroyed an object may have many different logical owners in different parts of an application and generally they don't know about one another so reference counting is way to make sure that an object does not get destroyed before while it is still in use before it is no longer useful so CF retain which is one of the polymorphic functions is used to what we call take a reference or increment the reference count of a CF object this is sometimes called having a retain on the object as well because it's CF retain is used to increment the reference count the function CF release is used to give up your part ownership in an object core foundations objects automatically destroy themselves when their reference count drops to zero you don't need to do that but you do need to get rid of any references that you do have and I'll be talking about that if you have a variable which is referencing a core foundation object but no retain on the object it could be destroyed out from under you at any time and there is really no way to find out that this has happened there is a date that's called a dangling reference and dangling references just as in you know Mac OS 9 or any other system can cause app misbehavior or a crash sometimes an retain is automatically given to you see if retain is used to explicitly take a reference but sometimes a retain is automatically given to you when you get an object say as a return value these automatic retains in addition to the ones you explicitly do with CF retain must be released later when you no longer need the object if you don't do that the memory is not going to be freed and you're gonna have a leak which will cause your app to use more memory than it needs to so you have to know when you need to explicitly make yourself an owner of a object and know when you have been given an ownership in an object and this is a fundamental question that arises for a developer how to do I own this particular object to answer that question we develop conventions for core foundation as our example we're going to look at the naming convention for functions which return core foundation objects as that is by far the most significant convention by convention in core foundation if a function returns an object of a core foundation type it uses the verb get if it is returning the object to you but not giving a retain on that object to you as well that is it is not automatically returning a part ownership in that object to you for example CF Dictionary get value would return the value out of a CF dictionary but would not give you a retain increment the reference count automatically on that object and you should not release values which are returned from get functions or you will create a dangling reference functions which automatically do retain a returned object for you use either the verbs copy or create depending on what the function is doing functions which create new instances use create for example the objects you receive by calling a create or copy function must have that retain released by you when you are done with that object or you're going to have a leak this is so important it really deserves repeating get functions never automatically increment the reference count create functions and copy functions always increment the reference count of objects that they are returning so these conventions are for the programmers benefit they're easy to remember and they're you know ways for you to know automatically when you see an API what is happening with respect to the memory management of that returned object but the use of the copy and create as verbs should not be taken to mean that objects are always being copied or created a copy or a new object would not be created when it's not appropriate for example sometimes it's done for efficiency another example would be a type which kept a cache of all the objects for example that hit it had created because it was unique in them in some way create function might return an object out of the cache rather than making a new one but the reference count on that returned object is always incremented whether it's a cached object or a new one well and by the way such a cache will probably be implemented often be implemented by using a CF dictionary as I discussed earlier okay there's one final general facility that I'm going to discuss before we move on to talking about some of the higher-level application services in corefoundation that's what we call toll-free bridging this is mostly a benefit for cocoa applications and frameworks but it also helps a lot in a mixed cocoa and carbon environment some of the basic data types and core foundation are bridged to their cocoa counterparts such that the core foundation type and the cocoa type are interchangeable as the example at the bottom shows a simple cast is all that's needed to convert the cocoa and a string to a core foundation CF string ref and vice-versa to convert a CF string a cocoa NS string this allows these core foundation and cocoa objects to be easily shared and passed around the different layers in the Mac os10 architecture the list of core foundation bridge types is in the foundation release notes on the system I haven't listed them here okay now I'd like to introduce Doug Davidson who will take us through some of the application services available from core foundation Doug thanks Chris so first I'm going to talk briefly about some basic application services available on both Mac OS 9 and Mac OS 10 that probably most applications are going to want to use and then I'm going to go into a little more depth on some advanced application services that core foundation provides on Mac OS 10 so let's start with the basic application services yep bundle C up plugins yep preferences so what is a bundle a bundle is a way of collecting all the resources associated with an executable into a single object what can you put in a bundle you can put in executables obviously multiple executables perhaps you can have different versions of your executables for Mac OS 9 and 4 and for Mac OS 10 you can have resources of various types you can have resource files both localized and non localized you can have resource manager style resources again both localized and non localized and in any number of localizations you can have you have a property list the info dictionary for the bundle which can contain essentially arbitrary metadata about that bundle you can have libraries you can have plugins you can put in essentially any kind of file of folders you want into the bundle and CF bundle is the programmatic interface for dealing with bundles it has functions that allow you to locate any of these objects within the bundle C a bundle is the heart of our localization strategy this is what allows us to ship back os10 simultaneously in many different languages because what C a bundle will do is automatically provide you with the correctly localized version of any particular resource based on the user's preferences see a bundle also has some basic code loading facilities that is it can load code and allow you to look up symbols within it and in particular it can do this transparently whether the code you're loading or whether the code that is doing the loading is mokou or CFM on Mac OS 10 some of you have probably already use this facility for example to allow CFM executables on Mac OS 10 to use functionalities from Mach o frameworks now the functionality to see a bundle provides is enough for basic loading of plugins that is you can load it and you can look up entry points within it but what it doesn't do is manage the interface between the host and the plug-in for you for that we have a specialized kind of see a bundle called CF plug-in now it's possible you may already have an interface between host and plugin that you use and in that case you might not be interested in see a plug-in but if you're looking for such a thing you might want to consider CF plugin I'm not gonna explain in detail how it works now it works the the host looks up interfaces by you you IDs where the interfaces are C++ or com style tables of function pointers those get passed back the best place to learn about this is through some examples that we have both in the core foundation documentation on Mac OS 10 and in the carbon Lib SDK you'll also find that there are a few places on the system where we use CF plug-in as our interface for plugins for example for plugins for the printing subsystem on Mac OS 10 and finally CF preferences this is our general facility for small flexible application preference storage and these preferences are usually both per user and per application although there are other possibilities and the way this works is that any particular preference is referred to by a name which is just a CF string key and the value of the preference can be any property list type so it's very flexible all you do to store a preference is just set that preference for the name key the name and you just look it up by name when you want it and see a preference this takes care of everything else handles all the storage for you currently they're stored using the flattened XML representation for property lists there are a couple of caveats this is not intended for huge caches or large chunks of binary data or anything like that also you need to be sure that anything your application absolutely relies on is not stored here these are stored external to the application and it's possible that users could erase their preferences you should be prepared for the possibility that preferences are missing or corrupt it for some reason but it is a very valuable general facility we use it all over the place many of our system preferences are stored in this play for example the users language preferences that I mentioned in the case of CF bundle are stored using CF preferences okay next I want to go on to some advanced application services in Mac OS 10 starting with CF run loop which is the basis for the rest of these and then I'll discuss some things that our name will bias the front loop another run loop what is a run loop Carbon event-based applications and cocoa applications have something in common that is they're both fundamentally event-driven the way they work is events come in and pass to the application to be handled the controls return you wait for something else to happen again the fundamental mechanism that underlies this in both cases is the run loop now we call it a run loop because we say that it runs and that of loops but mainly what it does is it waits it waits for something interesting to happen tells you about it you handle it then it goes back and waits again and the thing it waits for can be any of a wide variety of things it might be the arrival of a mock message might be perhaps the arrival of a network packet it might be just the arrival of some specific time but the important thing about the run loop is that it can wait for all these things a wide variety of things simultaneously efficiently easily without pulling without using the processor resources this turns out to be a very powerful concept now each thread has exactly one run loop object now there may be many interfaces to it corefoundation through carbon through cocoa they're all dealing with the same underlying object you can use any or all of them typically you would want to use the highest level interfaces suit your purposes often you will be using it through carbon or cocoa but if you happen to be using a core foundation level source something that the core foundation level does the run that can wait for then you would want to use the core foundation interface to it which is CF run Luke now one thing about run ups is that you may not want to wait for any possible type of event source at any given time for example you might not want a certain timer to fire while you are tracking Mouse moves or something like so run loops have something called modes at any given time the run up is running in a specific mode and any particular source is registered with a run loop for only a certain set of modes so for example in cocoa there are a couple of specific defined modes that cocoa use this one the modalpanel run loop mode is used when it there are modal panels up and it's waiting on that there's another one that's used when typically when the mouse is being tracked but normally the run won't be used and run in the default mode and when you register a source with the run loop you can register it with a specific mode or set of modes or you can choose to register what this will call common modes which is a set of modes determined by your application environment in cocoa would be the default mode plus the modal panel and event tracking modes now the run loop by itself is not terribly interesting what's interesting are the things that it enables the things you can do with it primarily the things that can wait for so at the core foundation level some of the things that could wait for are well first of all you can use it to wait for raw mock messages or raw network packets now if you want to do that you can we have a CF mock port for waiting for raw mock messages or CF Saka for waiting for events on a socket that's useful for example if you have if you are in a carbon or cocoa application and you want to wait for these things you don't have to spawn a separate thread to do that you can simply be notified you can get a function callback within your main event loop and I'm going to go into some other Co front loop sources in just a moment you can create your own it is a little tricky to do so so another thing I said is you could wait for it's just the arrival in a specific time and you can wait for a single time or repeating sequence of times with a CF remove timer what you do is you create the timer tell it what time or times to wait for and you tell it what function will be called back on that time arise if then you attach it to run loop in a given mode or set of modes and when the run loop is waiting in one of those modes it checks to see if your time has arrived and if your time has arrived then you get a callback now if you're waiting for a single time then the timer is automatically and validated after that time has arrived and the timer is fired if you're waiting for a repeating sequence of times then you would have to invalidate the timer yourself when you're done with it now I talked about romic messages they have a lot of advantages there the the fundamental low level local IPC mechanism and Mac OS 10 but and that they're very powerful in high performance and they have a lot of flexibility but they can be difficult and tricky to use so we also have a slightly just one higher level one level up mechanism built top of them in core foundation called CF message port which is a high-performance low overhead local IPC mechanism and you can use it either asynchronously sending messages one-way or synchronously sending a message in getting a reply the way you use CF message port is that you create a local message port on one end and that these pill ports can be advertised to other processes on the system with a name which again is just a CF string and you create a remote message port looked up by name to represent the other end the end what you're sending does the message that you send is just a CF data that is a collection of bytes plus optionally a message ID manager and the reply if you want to get a reply back is a CF data so what the intended receiver of the message will do is to publish as API the protocol for this message that is how to interpret the data or the message ID of both and whether they'll be apply and how that should be interpreted the sender would create a remote message port to represent the port the destination of the message and call CF message ports and requests with a message to be sent then the receiver will be notified within its run loop getting a callback and then if there's a reply the receiver would return there apply and then the sender would get their reply and the message port send would return now there's also another mechanism that we have built on top of these which is perhaps lesser known but very useful and this is a broadcast local IPC mechanism CF notification center and what this allows you to do is to post happenings of any sort to an arbitrary possibly unknown set of receivers these notifications are identified by their name and optionally also by another string that the name again is just a CF string optionally also by another string representing the object that sends them and they can carry with them essentially arbitrary data again a property list in this case the sender would specify what sort of notifications it's going to send out what their names would be and what sort of information they would carry with them and when the sender wants to send one of these notifications it simply posts it and goes on its way it may choose whether the notifications are going to be delivered immediately or not the receivers if anyone anyone on the system who wants to receive such a notification simply registers to receive it senator doesn't have to know anything about them you register based on the name optionally also the string representing the sender and you can choose whether you want to receive these notifications immediately or whether you want them to be delayed because typically it's not necessary for all the receivers to get the notification at once and it's rather expensive to wake them all up wake up all these processes at once to deliver the notification often it's enough if you will simply get this notification the next time you become active and if you a notification might be send multiple times you can choose to have those coalesced if you like so this is very useful mechanism it's not intended for large amounts of data or very high volume of frequency but it's useful in a variety of circumstances especially for example in combination with other channels of information for example if you had a suite of applications on the system that all shared a set of preferences and one application was going to change those preferences it could send out a notification to let all the other applications in the suite know the preferences have changed and then at their convenience they can look up the change value or if you had some area on the file system that you were working with you changed it you could send out a notification to let any interested party know that it had changed and that they should go and look it up and see what had happened all right so now let's discuss where you can go for more information about corefoundation there is documentation on your system and online there are a number of examples both with your Mac os10 developer CD and then the carbon Live SDKs and you should not forget to look at the release notes which describe anything new or anything that has changed in corefoundation and there are some specialized release notes that are more like discussions of topics and depth one on C a bundle and C a plug-in with some detailed examples C a plug in one describing the info dictionary and a bundle in detail and one on localization and now I'd like to bring mark Turner back to wrap things up and star a QA Oh we'll take a quick look at well I was gonna say what the roadmap is but let's talk about this so yeah as I said I'm the carbon technology manager although a core foundation is obviously not a carbon specific technology I'll be happy to take your questions or comments about core foundation you can email me at mark at apple.com there is the email address here which is read by the engineering team so that's another great place to send your feedback and these two mailing lists I encourage you to to get on if you're not already it's a great place to get your questions answered and share your knowledge about carbon cocoa and corefoundation these lists are available if you haven't been there before there's a webpage at lists Apple comm where you could sign up for a great many Apple mailing lists and now so here we are 10 o'clock Friday morning most of these sessions have gone by already but I'd like you to I'd like to highlight them for you so that you can look at them on a DC TV or on the DVDs when you get them first being the cocoa overview that's a great session just for those of you who haven't gotten started yet with cocoa the carbon event manager is another overview session for carbon developers we really encourage you to look into the carbon event manager it simplifies your code and gets you much better performance on Mac os10 and then the advanced cocoa topics session which we had yesterday for more information about the run loop and other things that Doug mentioned and if you're here this afternoon the cocoa feedback forum would be a great place to bring your questions about cocoa and of course corefoundation because many of the same people will be there you