• 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: Cocoa Technologies Back-Story?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa Technologies Back-Story?


  • Subject: Re: Cocoa Technologies Back-Story?
  • From: Bill Bumgarner <email@hidden>
  • Date: Mon, 2 May 2005 08:57:22 -0700

On May 1, 2005, at 9:38 AM, Scott Stevenson wrote:
If the application is primarily computational instead of data management oriented, I would probably not choose CoreData. I doubt Core Data can substantially automate or improve a ray tracer, a fractal generator, a PDF viewer, an industrial equipment controller, a low level DVD burner, many games, etc.


At least true for Core Data 1.0. They've left themselves a lot of room to grow.


Actually, I'd pull the PDF viewer out of that list, since you could do some rather interesting things with large documents with a lot of reference.

Also, I'd pull "Industrial Controller" as a lot of that particular problem is often focused on storing a boatload of relatively simple and regular data to be fed to the machine. Likewise "ray tracer". Core Data could be very useful in a gaming context, too, given that modern games often seem to be backed by more and more data.


In general, Core Data will be useful in any context where you have a boatload of data that can be represented by a graph of objects.

Now, with that said, Core Data does not help you write highly optimal "engine" type code like, say, a ray tracer, fractal generator, or what might be used for industrial purposes.

Also, Core Data is not well suited to storing free form documents -- word processing documents, for example -- as they are generally stored today. Now, that isn't a limitation of Core Data so much as a result of how said documents are represented. The Text subsystem has a very particular fashion of storing all of the rather complex data necessary to save away document formatting. Unless you dive into the intricacies of the text subsystem, most of the storage and retrieval of said formatting can be treated as a black box.

It would certainly be possible to represent free form documents in Core Data. It is just a problem of developing an effective model.

On 30 Apr 2005, at 22:56, Daniel Jalkut wrote:
I am troubled by the "it fell out of the sky" aspect of some newer Cocoa technologies.

Core Data certainly did not "fall out of the sky". Numerous prior technologies were considered very carefully when designing Core Data. If you have WebObjects installed, you might find that many API searches will return hits in both Core Data and EOF for any given method. That is not coincidental.


b.bum


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Cocoa Technologies Back-Story?
      • From: Marcel Weiher <email@hidden>
    • Re: Cocoa Technologies Back-Story?
      • From: Scott Stevenson <email@hidden>
    • Re: Cocoa Technologies Back-Story?
      • From: John Stiles <email@hidden>
References: 
 >Re: Cocoa Technologies Back-Story? (From: Scott Stevenson <email@hidden>)

  • Prev by Date: Re: Creating a Cocoa Help Book
  • Next by Date: Re: Tiger gcc 4 builds apps that don't run on 10.2.8
  • Previous by thread: Re: Cocoa Technologies Back-Story?
  • Next by thread: Re: Cocoa Technologies Back-Story?
  • Index(es):
    • Date
    • Thread