Why Cocoa (say vs Carbon)

  • Hi,

    This is really elementary, but I haven't done any Objective-C
    development before.

    I have a carbon app now that I "inherited"

    I don't need an OS 9 version, so I was thinking about re-writing the
    app in Objective-C.

    Can anyone tell me why I should do this? I mean are apps faster,
    respond better? What does making it OS X native really gain me?

    -Jason
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 02:46  PM, J. Todd Slack wrote:

    > Can anyone tell me why I should do this? I mean are apps faster,
    > respond better? What does making it OS X native really gain me?

    Here's a nice brief intro:

    http://realbasic.com/realbasic/about/Carbon_vs_Cocoa.html

    -- Tito
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 08:57 AM, Tito Ciuro wrote:

    ...but be advised of two things:

    1) While mostly accurate, it does contain some glaring inaccuracies
    (e.g. Cocoa applications can't access all carbon functionality)
    2) It is a sales pitch for (i.e. propaganda) for RealBasic and the
    purpose of the article is to explain why RealBasic is better than both
    Carbon and Cocoa, which skews the data.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 05:12  PM, Jeff LaMarche wrote:

    > ...but be advised of two things:
    >
    > 1) While mostly accurate, it does contain some glaring inaccuracies
    > (e.g. Cocoa applications can't access all carbon functionality)
    > 2) It is a sales pitch for (i.e. propaganda) for RealBasic and the
    > purpose of the article is to explain why RealBasic is better than both
    > Carbon and Cocoa, which skews the data.

    Number two is inaccurate. It was written to explain that Cocoa and
    Carbon are coequals that access the same underlying functionality (Core
    Foundation). And that applications written using Carbon offer
    essentially the same capabilities as those written in Cocoa (granted
    you'll have to write a lot more code in Carbon to get that
    functionality).

    REALbasic is not advertised as being better than Carbon, because
    REALbasic *is* a Carbon-based development environment, and as such,
    their paths are linked.

    Bob
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Contrary to the RealBasic article: Cocoa can be used conveniently with
    Objective-C, Objective-C++, Java, and several scripting languages.
    Cocoa can be used less than conveniently with ANSI C, ANSI/ISO C++, and
    any language that can call C functions.

    Contrary to the RealBasic article: Apple's Foundation Kit is largely
    replicated by gnustep which makes many Foundation applications very
    portable.

    Cocoa is derived from Openstep which was ported to many platforms
    including Windows NT.  Openstep delivered what Java has only promised
    IMHO.

    Cocoa is a very elegant collection of object oriented frameworks that
    provide a highly productive environment for writing many kinds of
    software.

    If Cocoa is used with Objective-C or Objective-C++, the Cocoa code can
    be freely intermixed with existing C/C++ code including Carbon code.
    This is a good thing because many features of Mac OS X can only be
    accessed with C APIs at this time.

    Contrary to the RealBasic article: Objective-C was not invented by
    Apple or NeXT and has never been restricted to those environments.
    Objective-C is included with the Gnu Compiler Collection (gcc) and has
    been available from multiple sources since at least 1988.

    I don't recommend rewriting Carbon software that already works unless
    it was going to be largely rewritten anyway. If it aint broke, don't
    fix it. When starting almost any large software project, Cocoa is a
    huge productivity, elegance, and features win over alternatives
    including RealBasic IMHO.  I think there is a glass ceiling for
    RealBasic applications.  They don't scale to full blown full featured
    applications. Cocoa has no such limits.

    I think Cocoa is the best general purpose software development
    technology yet made, but I admit the opinion like most is subjective
    and others have different opinions.

    On Wednesday, February 26, 2003, at 08:57 AM, Tito Ciuro wrote:

    > On Wednesday, February 26, 2003, at 02:46  PM, J. Todd Slack wrote:
    >
    >> Can anyone tell me why I should do this? I mean are apps faster,
    >> respond better? What does making it OS X native really gain me?
    >
    > Here's a nice brief intro:
    >
    > http://realbasic.com/realbasic/about/Carbon_vs_Cocoa.html
    >
    > -- Tito
    > _______________________________________________
    > cocoa-dev mailing list | <cocoa-dev...>
    > Help/Unsubscribe/Archives:
    > http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    > Do not post admin requests to the list. They will be ignored.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 06:09 PM, Robert Steely wrote:

    >
    > REALbasic is not advertised as being better than Carbon, because
    > REALbasic *is* a Carbon-based development environment, and as such,
    > their paths are linked.
    >

    So you don't think the following quote from the cited page is an
    advertisement ?:

    <Quote>
    The fact is that while Cocoa provides a richer set of functions than
            Carbon, REALbasic provides you with a far richer set of
    functions than            Cocoa does. Writing an application in
    REALbasic takes far less time            and is far easier to
    accomplish for the typical user than it would be            in Cocoa.
    And applications written in REALbasic can run on Mac OS            8,
    Mac OS 9, Mac OS X, and Windows 95 through Windows XP. Don't
    just take our word for it, you can convince yourself. Download the
    Objective-C            tutorial (in which you create a currency
    calculator) from Apple's web            site. Now create the same
    currency calculator in REALbasic. With that            exercise, you
    will convince yourself.
    <End Quote>

    I would further add that IMHO the author is clearly out of his mind if
    he thinks what he says is true for "real" applications and not just
    toys.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • I think it is somewhat biased towards Carbon, since RealBasic is based
    on Carbon.

    It also does not discuss the differences between _programming_ in Cocoa
    versus in Carbon, since it is oriented around RealBasic. The greatest
    advantages in Cocoa are in the development environment, the language
    and the API. Real obviously has no interest in making Cocoa look good.

    / Rgds, David

    >> ...but be advised of two things:
    >>
    >> 1) While mostly accurate, it does contain some glaring inaccuracies
    >> (e.g. Cocoa applications can't access all carbon functionality)
    >> 2) It is a sales pitch for (i.e. propaganda) for RealBasic and the
    >> purpose of the article is to explain why RealBasic is better than
    >> both Carbon and Cocoa, which skews the data.
    >
    > Number two is inaccurate. It was written to explain that Cocoa and
    > Carbon are coequals that access the same underlying functionality
    > (Core Foundation). And that applications written using Carbon offer
    > essentially the same capabilities as those written in Cocoa (granted
    > you'll have to write a lot more code in Carbon to get that
    > functionality).
    >
    > REALbasic is not advertised as being better than Carbon, because
    > REALbasic *is* a Carbon-based development environment, and as such,
    > their paths are linked.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 07:03  PM, publiclook wrote:

    >>
    >> REALbasic is not advertised as being better than Carbon, because
    >> REALbasic *is* a Carbon-based development environment, and as such,
    >> their paths are linked.
    >>
    >
    > So you don't think the following quote from the cited page is an
    > advertisement ?:
    >
    > <Quote>
    > The fact is that while Cocoa provides a richer set of functions than
    > Carbon, REALbasic provides you with a far richer set of
    > functions than            Cocoa does. Writing an application in
    > REALbasic takes far less time            and is far easier to
    > accomplish for the typical user than it would be            in Cocoa.
    > And applications written in REALbasic can run on Mac OS            8,
    > Mac OS 9, Mac OS X, and Windows 95 through Windows XP. Don't
    > just take our word for it, you can convince yourself. Download the
    > Objective-C            tutorial (in which you create a currency
    > calculator) from Apple's web            site. Now create the same
    > currency calculator in REALbasic. With that            exercise, you
    > will convince yourself.
    > <End Quote>

    That does sound like an advertisement, doesn't it? ;)

    > I would further add that IMHO the author is clearly out of his mind if
    > he thinks what he says is true for "real" applications and not just
    > toys.
    >
    Like any development environment, it has its strengths and weaknesses.
    RB's strengths are in rapid development (memory management is easier
    and debug cycles are shorter) and cross-platform compatibility
    (Classic, Carbon, and Windows). However, C-based code tends to be
    faster than RB code (compiler not yet optimized) and Cocoa applications
    are significantly smaller that RB (Carbon-based) apps.

    I use both and try to pick the best development environment for any
    given task.

    But to get back to the original intent of the thread, I'd choose
    ObjC/Cocoa to C/C++/Carbon development every day of the week and twice
    on Sundays. As a Cocoa novice, I'm amazed at the power of the Cocoa
    APIs. Especially drool-worthy is the ability to build a multi-document
    text editor, that features rich text, imbedded graphics, rulers, text
    justification, and a myriad of other features that requires practically
    no code of my own.

    Can't wait to learn more!

    Bob
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 06:55 PM, publiclook wrote:
    > Cocoa is derived from Openstep which was ported to many platforms
    > including Windows NT.  Openstep delivered what Java has only
    > promised IMHO.

    ...and then took it away again. OpenStep for Windows is no longer
    available, unfortunately.

    mathew
    [ If it *is* available, it's very well hidden... ]
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 06:55  PM, publiclook wrote:

    > I don't recommend rewriting Carbon software that already works unless
    > it was going to be largely rewritten anyway. If it aint broke, don't
    > fix it. When starting almost any large software project, Cocoa is a
    > huge productivity, elegance, and features win over alternatives
    > including RealBasic IMHO.  I think there is a glass ceiling for
    > RealBasic applications.  They don't scale to full blown full featured
    > applications. Cocoa has no such limits.

    I had exactly that experience recently, when trying to developer a
    major new application--I found myself fighting the language, the IDE,
    the debugger, and the general flakiness of the 4.x releases and 5.x
    betas. I eventually realized it wasn't worth it, because I was living
    in a kind of "no man's land" that wasn't really Carbon and it wasn't
    really Cocoa (perhaps necessarily, since RB is cross-platform).

    I thought of sharing my experience on the RealBasic developer list and
    recommending that for all the eventual complexity that RB developers
    experience, they could just as well learn Cocoa, but thought better of
    it--why rain on their little parade?

    > I think Cocoa is the best general purpose software development
    > technology yet made, but I admit the opinion like most is subjective
    > and others have different opinions.

    Amen!

    (Though the REAL secret weapon is Python + Cocoa: PyObjC--now you're
    writing Cocoa apps in one-third to one-tenth the code.)

    Cheers!
    --Chris Ryland / Em Software, Inc. / www.emsoftware.com
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Yes, that is very cool... but, IMO, it's very misleading.  While it is
    true that I am much more productive with Cocoa than I ever was with the
    old MacOS/Carbon APIs, there is still work to be done with Cocoa code.
    Watching the demo of the word processor being built in less than 15
    minutes makes a great marketing story, but it builds up the
    expectations a bit much :)  Unless, of course, you're writing a word
    processor ;)

    Cocoa's main advantage is that it allows you to work on the
    functionality of your code, vs trying to make the OS do what it's
    supposed to do.  I still have nightmares about all of the setup code
    that classic MacOS programs required... initializing the various
    managers, setting up an event loop -- I'm sure all the old Mac
    programmers remember having to write code to allow windows to be
    dragged... what a freaking nightmare.

    And, it's not much better on the Windows, Java, or X Windows side,
    IMO... none of them beat the for-free, out of the box, standard
    development environment of Cocoa.  Boy, it would be nice to see Apple
    port Cocoa back out to Windows, Solaris, and others (Linux port? :)
    again... maybe in a few years once everything settles with OS X.

    dennis

    On Wednesday, February 26, 2003, at 07:44 PM, Robert Steely wrote:

    > Especially drool-worthy is the ability to build a multi-document text
    > editor, that features rich text, imbedded graphics, rulers, text
    > justification, and a myriad of other features that requires
    > practically no code of my own.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Sure they do, you could do the same  example Rich Text Editor with
    almost now handwritten code on Windows.  All you had to do was use
    Visual C++ ($1400), MFC (leaks memory like a sieve) and learn how to
    translate that arcana of Message Crackers.

    And once you've done all this, you feel like an accomplished C++
    developer, only to go apply what you've learned and discover that much
    like the rest of Windows, you've now gone beyond the glossy surface to
    find the ugliness that lurks beneath.

    I'm finding some of the same things in Cocoa, features that strike me
    as implemented in odd places.

    That said, overall, Cocoa just *feels* like a better toolset, and
    having only spent the time to download the toolset, I can't really
    gripe now can I?

    Maybe I can.

    Things that would make the Cocoa / Project Builder / Interface Builder
    world a better place, one that would make the average enterprise level
    developer drool?  Code completion code-insight, whatever you want to
    call it.  But the little popup's that provide the parameter list for a
    given method, a popup to offer the closest match as you type for a
    method name, and a better way to browse documentation (I find that the
    in application methodology of both Visual Studio and Project Builder is
    a disaster) to the point where I use a seperate window with the docs in
    that to be able to work productively as a new to Cocoa developer.

    The other thing the is missing is a data access model. A framework to
    wrap the fancy ODBC Manager in Jaguar, with some basic ODBC drivers
    would be a perfect start.  Leverage Apple software, and provide a
    framework to the ODBC datasources and an ODBC driver for FileMaker, or
    the WebObjects supplied OpenBase.

    And for the sake of really grabbing developer mindshare?  drop the
    price of WebObjects, or bundle it ala IIS and .NET.  I've spent the
    past year doing C#.NET work in a Fortune 1000 shop, and Cocoa &
    WebObjects flat kill it for function and form, but being the only Mac
    user in the shop ( that isn't a graphic artist in the
    monkeying^H^H^H^H^H^H marketing department ), I'm kinda outvoted.  But
    a platform that offers world class tools (PB/IB/WO are damned close)
    for a sub $600 / machine pop is an awfully sexy sale.

    Ok, I'm done ranting now....

    Andy

    On Wednesday, February 26, 2003, at 08:57  PM, Dennis Munsie wrote:

    > And, it's not much better on the Windows, Java, or X Windows side,
    > IMO... none of them beat the for-free, out of the box, standard
    > development environment of Cocoa.  Boy, it would be nice to see Apple
    > port Cocoa back out to Windows, Solaris, and others (Linux port? :)
    > again... maybe in a few years once everything settles with OS X.

    > Especially drool-worthy is the ability to build a multi-document text
    > editor, that features rich text, imbedded graphics, rulers, text
    > justification, and a myriad of other features that requires
    > practically no code of my own.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 06:30  PM, Andy Satori wrote:
    > ...much like the rest of Windows, you've now gone beyond the glossy
    > surface to find the ugliness that lurks beneath.
    >
    > I'm finding some of the same things in Cocoa, features that strike me
    > as implemented in odd places.

    Out of curiosity, of what do you speak?

    Seth A. Roby            The Amazing Llama < mail or AIM me at tallama at mac dot
    com>
    "Life is like an exploded clown. It's really funny until you figure out
    what just happened."
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • This is one of those threads that get hijacked by the first response;
    as interesting as the debate on the RealBasic blurb is, I don't think
    it really addressed your original question.

    First of all, let's get something straight, Carbon _is_ OS X native. It
    is easier to access some OS X features from Cocoa (but still possible
    in Carbon). There have been arguments advanced on this list that Cocoa
    apps have some advantages for end users, but if you are looking for
    differences in the application as seen by end users you are missing the
    main difference between Carbon and Cocoa.

    The _big_ difference is that developing in Cocoa is much easier and
    faster than developing in Carbon. When writing new apps, Cocoa is
    definitely the path of least resistance.

    Now, if you are starting with an existing body of Carbon code, you have
    to consider the following: working, debugged code is very
    labor-intensive to produce, so if you are starting with a large body of
    working, debugged code in Carbon, it may very well not be worth the
    effort to rewrite in Objective-C.

    Personally, I am rewriting a couple of apps that I have developed in
    Carbon. The reason is that I intend to significantly extend these apps
    (in one case I was intending to rewrite it anyhow) and the amount of
    existing code is relatively small. Even so, i can reuse some of the
    code (that is not tightly tied to Carbon). The rewrite effort will be
    justified in the amount of time I save in doing the extensions.
    However, if you have a lot of code and the extensions required are
    relatively modest, it would not be worth the effort to rewrite. I would
    surmise that most large Carbon apps fit into this category (not being
    worthwhile to rewrite).

    To reiterate, advantages to the end user don't weigh heavily in the
    decision to rewrite because a Carbon app can support virtually all OS X
    features, although in some areas it requires more effort and not all
    Carbon developers have completely availed themselves of all the
    opportunities to do so (this situation is slowly improving with time).
    The main advantage of Cocoa is the ability to more effectively leverage
    the developer's time.

    So, you have to ask yourself what you intend to do with this app you've
    inherited. Will you be adding a lot of new code? How much code is there
    now?

    - Dennis D.

    On Wednesday, February 26, 2003, at 05:46 AM, J. Todd Slack wrote:

    > Hi,
    >
    > This is really elementary, but I haven't done any Objective-C
    > development before.
    >
    > I have a carbon app now that I "inherited"
    >
    > I don't need an OS 9 version, so I was thinking about re-writing the
    > app in Objective-C.
    >
    > Can anyone tell me why I should do this? I mean are apps faster,
    > respond better? What does making it OS X native really gain me?
    >
    > -Jason
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • At 9:30 PM -0500 2/26/03, Andy Satori wrote:
    > The other thing the is missing is a data access model. A framework
    > to wrap the fancy ODBC Manager in Jaguar, with some basic ODBC
    > drivers would be a perfect start.

    I think the existing Objective-C version of EOF, with an ODBC adaptor
    that works through iODBC, would be a perfect start.

    Let Apple know that you want this via the bug reporter.  File an
    enhancement request.  The more people that can honestly say "I can
    help you sell more Macs with EOF in this concrete way" the more
    likely it is that Apple will come to its senses and revive the darned
    thing already.

    (It's only been THREE YEARS since we Cocoa developers started saying
    we needed EOF in Objective-C.  It's time, Apple.  It's time.)

      -- Chris

    --
    Chris Hanson, bDistributed.com, Inc.  |  Email: <cmh...>
    Custom Application Development        |  Phone: +1-847-372-3955
    http://bdistributed.com/              |  Fax:  +1-847-589-3738
    http://bdistributed.com/Articles/    |  Personal Email: <cmh...>
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • > Things that would make the Cocoa / Project Builder / Interface Builder
    > world a better place, one that would make the average enterprise level
    > developer drool?  Code completion code-insight, whatever you want to
    > call it.  But the little popup's that provide the parameter list for a
    > given method, a popup to offer the closest match as you type for a
    > method name, and a better way to browse documentation (I find that the
    > in application methodology of both Visual Studio and Project Builder
    > is a disaster) to the point where I use a seperate window with the
    > docs in that to be able to work productively as a new to Cocoa
    > developer.

    I guess they're following the 'you get it for free, so don't complain'
    mantra. I'd personally would love if, failing that, Metrowerks stepped
    up to that plate (they still need to debug their C++ code completion a
    lot, but that's far harder than doing code completion for Objective-C).
    As I do cross-platform development and so end up paying for the updates
    every year or so, getting that from them would make me one of the
    happiest men on earth.

    > The other thing the is missing is a data access model. A framework to
    > wrap the fancy ODBC Manager in Jaguar, with some basic ODBC drivers
    > would be a perfect start.  Leverage Apple software, and provide a
    > framework to the ODBC datasources and an ODBC driver for FileMaker, or
    > the WebObjects supplied OpenBase.

    Well they are running out of things to put in 10.3, aren't they? ;) At
    least one can only hope...

    At the very least they should make it available for OS X server.

    Hope that helps.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • > Things that would make the Cocoa / Project Builder / Interface Builder
    > world a better place, one that would make the average enterprise level
    > developer drool?  Code completion code-insight, whatever you want to
    > call it.  But the little popup's that provide the parameter list for a
    > given method, a popup to offer the closest match as you type for a
    > method name, and a better way to browse documentation (I find that the
    > in application methodology of both Visual Studio and Project Builder
    > is a disaster) to the point where I use a seperate window with the
    > docs in that to be able to work productively as a new to Cocoa
    > developer.

    Have you tried PBXtra (www.culater.net/osd/PBXtra/PBXtra.html). I makes code
    completion and show you a pop-up with methods. The program is not perfect and
    is sometimes annoying but it does the work (it's on version 0.3). I usually
    use it, and I'm  quite happy with it.

    Ignacio Bonafonte
    <nachob...>
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Wednesday, February 26, 2003, at 09:30 PM, Andy Satori wrote:

    > The other thing the is missing is a data access model. A framework to
    > wrap the fancy ODBC Manager in Jaguar, with some basic ODBC drivers
    > would be a perfect start.  Leverage Apple software, and provide a
    > framework to the ODBC datasources and an ODBC driver for FileMaker, or
    > the WebObjects supplied OpenBase.

    Sounds like you're describing EOF. Unfortunately, it's only available
    for Cocoa if you've got WebObjects, something that a great many of us
    have griped about in the past.

    > And for the sake of really grabbing developer mindshare?  drop the
    > price of WebObjects, or bundle it ala IIS and .NET.  I've spent the
    > past year doing C#.NET work in a Fortune 1000 shop, and Cocoa &
    > WebObjects flat kill it for function and form, but being the only Mac
    > user in the shop ( that isn't a graphic artist in the
    > monkeying^H^H^H^H^H^H marketing department ), I'm kinda outvoted.  But
    > a platform that offers world class tools (PB/IB/WO are damned close)
    > for a sub $600 / machine pop is an awfully sexy sale.

    On the contrary, WO's price is extremely competitive; the price is not
    what's holding WO back - Apple's lack of marketing is, as well as the
    perception of many that products made by Apple have no place in the
    Enterprise. I do agree that PB could use some enhancements, but WO can
    compete on it's merits, it just usually doesn't get a chance to even be
    considered.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
previous month february 2003 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28    
Go to today