• 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/EOF for non-enterprise apps Re: proof of cocoa superiority?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?


  • Subject: Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
  • From: Brian Hill <email@hidden>
  • Date: Tue, 12 Jun 2001 13:39:42 -0500

On Tuesday, June 12, 2001, at 07:59 AM, Bill Bumgarner wrote:

If your toolbox contains nothing but a hammer...
.... all the problems look like nails.

I'm certainly not going to make any kind of a claim that EOF isn't anything but the best tool in the world for building 2 tier and 3 tier applications that use a relational-- or, at least, fixed structure tables-- as a backing store. It is. It kicks major butt. Any developer who still thinks it is necessary to write SQL by hand as a normal part of n-tier app development is wwwaaayyy behind the times....


Agreed. However, unless I want to re-write all of the applications that I originally deployed on OSX Server 1.2 in a different language, I'm going to have to go back to writing SQL by hand (or create and connect all of my EOAssociations programmatically).

I think that point that keeps getting missed here is that we were shipped a product that didn't work. WO 4.5.1 was advertised as a way to move ObjC/EOF apps to OSX until they can be ported to Java. The fact that they neglected to update the EOPalette.palette for OSX means that it can't be used to move ObjC/EOF apps to OSX, as advertised.

Apple is aware that some kind of a generic persistency solution completely different from EOF needs to be provided to the developer. Ernie P. repeated this point at several sessions at WWDC.



Certainly, there is a tremendous amount of value within and knowledge to be gained from the feature set of EOF, but that does not make it a good tool to solve the generic desktop persistency problem.

This speaks to a different issue. You have a point, but that is not the problem.


b.bum

BTW: Stating that the "power of EOF for desktop apps" is not currently available is inaccurate. Have you actually tried working with the pure Java EOF in WO 5.x targeted to building Cocoa applications? It works fine. There are some rough edges at the adaptor level, but they are no worse than the rough edges in the native adators and it is extremely refreshing to be able to pop off to Sybase's or Oracle's web site, grab the latest and greatest JDBC adaptors, and have them *just work*.


Obviously, a remaining issue is one of licensing and it will be interesting to see how Apple addresses that issue. Let's hope it is handled with a bit more finesse than some of the licensing events in past history....

When I used to work with a different MacOS database product on OS9 (4th Dimension), I noticed the same split among the developer base as I see with WebObjects.

On the one hand, there is/was a thriving independent consultant segment which has one set of needs. As far as WebObjects goes, this is the segment that I heard shouting so loudly in support of the 'Pure Java' transition. There is no justification for the move to Java other than for this segment of developers.

On the other hand, there is/was those small businesses that use the product for internal vertical market applications. They (we) have a different set of needs.

For example, I don't care about distribution licensing. Most of my applications never leave the premises and never will. I don't really care much about 'mind share' and 'market share' either. I know the task I need to accomplish, I know the tool(s) that will allow me to accomplish it, and I do it. I have little reason to have to 'sell' my work to management -- as long as it works as it needs to, I've done my job. As long as I am to continue to accomplish those tasks, management will continue to allow me to populate our desks with Macs.

Here's where I get confused about what is happening: According to one side of Apple's mouth, small business/SOHO is a 'targeted market'. However, by examining their actions, it appears that WebObjects/EOF has been targeted toward consultant-type development, particularly those who use Windows NT.

Do we need Oracle connectivity at our small business? Nope, can't afford it, and OpenBase more than fulfills our needs. Do we need cross platform operation? Nope. We are Mac-based.

Please don't misunderstand what I'm saying. I'm not anti-Java.
I'm anti-paying-for-a-product-that-doesn't-work.

Thanks,

Brian

ps. It seems to me that most of the people who state that Java EOF/Cocoa desktop apps run just fine are actually running them on Windows NT clients. How would you rate the performance of a Java EOF thick client on MacOS X? During my testing with the WO5 beta, I found it to be nearly unusable. Did it improve *that* much in WO5 final on OSX clients? Does the VM still eat up 200MB of virtual memory for each application? Note that these are not rhetorical questions -- these are the reasons I've been giving up on Java/Cocoa applications.


email@hidden http://personalpages.tds.net/~brian_hill
___________________________________________________________
"Why? I came into this game for adventure - go anywhere, travel
light, get in, get out, wherever there's trouble, a man alone.
Now they've got the whole country sectioned off and you can't
move without a form. I'm the last of a breed."
-- Archibald "Harry" Tuttle, Rogue HVAC Repairman
___________________________________________________________


References: 
 >Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority? (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: NSTableView - "colspan" Multiple column spans?
  • Next by Date: How to add shared lib to PB?
  • Previous by thread: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
  • Next by thread: Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
  • Index(es):
    • Date
    • Thread