• 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: EOF Advocacy, Open Source?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOF Advocacy, Open Source?


  • Subject: Re: EOF Advocacy, Open Source?
  • From: Eric Peyton <email@hidden>
  • Date: Tue, 14 Aug 2001 15:07:58 -0500

On Tuesday, August 14, 2001, at 02:42 PM, Finlay Dobbie wrote:

On Tuesday, August 14, 2001, at 01:07 am, Scott Anguish wrote:

For example.. there are areas that Apple should take the lead in, that many apps required, and will give Cocoa developers a further advantage. In many cases this code already exists within Apple or in Private Frameworks. I.E. HTML, POP, IMAP, SMTP.

There are lots of private frameworks that Apple really should make public. It's silly, really. All that functionality is there, but if we want to use it we are supposed to re-invent the wheel.


I suppose it's probably because the APIs are changing, or something.


Or difficult to use (i.e. not documented), or on the road to going away, or poorly implemented in the first place, or Apple just doesn't want to support that SPI long term, or there is not time to clean the framework, document it, test it, etc. There are dozens of reasons why certain API's are not public. Supporting an API "forever" is a difficult and thankless task. Certain SPI's, if exposed, could lead to a support nightmare which would not allow Apple to move along as easily with the future of computing technology. (Certain proprietary antiquated operating systems have had this problem repeatedly in the past).

(Writing an SPI for a single application or group of applications is orders of magnitude easier than writing a publishable API. If you know your only application, then the SPI can be tailored and small errors in design can be easily handled in either the app or the framework. If you have to write a framework for public consumption - that possibly commercial apps would run on top of, you do NOT want errors in said API or the implementation underneath that API.)

Trust me when I say that what SPI is exposed as API is carefully thought out, goes through a peer and technological review, and is exposed (hopefully) for the right reasons. There are things that slip through the cracks and some things that just need to be out there in some form or another, but for the most part, the API's in OS X that are public are that way for a reason, as are the SPI's that are still private.

Eric


-- Finlay
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev


  • Follow-Ups:
    • Re: EOF Advocacy, Open Source?
      • From: Scott Anguish <email@hidden>
    • Re: EOF Advocacy, Open Source?
      • From: Nat! <email@hidden>
References: 
 >Re: EOF Advocacy, Open Source? (From: Finlay Dobbie <email@hidden>)

  • Prev by Date: classes chart
  • Next by Date: Re: classes chart
  • Previous by thread: Re: EOF Advocacy, Open Source?
  • Next by thread: Re: EOF Advocacy, Open Source?
  • Index(es):
    • Date
    • Thread