Re: Cocoa EOF
Re: Cocoa EOF
- Subject: Re: Cocoa EOF
- From: Yves Custeau <email@hidden>
- Date: Fri, 02 Jul 2004 10:55:09 -0400
Sorry but I don't have time for the "getting started" guide mainly if I need
to migrate what I have coded so far in EOF to the Obj-C/Espresso
As far as Obj-C it is really simple if you know Java or OO. Monday of this
week I knew absolutely nothing of Obj-C and now I'm doing pretty crazy
stuff.
Espresso could probably be compared to CodeData. It is lightweight compare
to EOF, it is not as deep and rich and the adapter level is limited too
(this one to OpenBase only). You have to take care of many things mainly
manipulating data relationships but it is very fast and coupled with
NSArrayController it provides a nice alternative to EODisplayGroups.
> From: Christian Evans <email@hidden>
> Date: Fri, 02 Jul 2004 10:23:58 -0400
> To: Yves Custeau <email@hidden>
> Subject: Re: Cocoa EOF
>
> Wow, any chance you could post a "little" getting started site
> somewhere?
>
> I would love to try some of what you are doing to get a little more
> emersed in Obj-C but I don't even know where to begin.
>
> Thanks,
> Christian
>
> On Jul 2, 2004, at 9:58 AM, Yves Custeau wrote:
>
>> Hello John
>>
>> Cocoa-Eof is 2-tier by default, unless you make some use of the WO
>> server in
>> between (through web services maybe). The Java-Client is 3-tier, there
>> is
>> some processing done at the Wo server level, you can define objects to
>> either run on the client or server.
>>
>> I'm currently developing a Cocoa-Java application (2 tier) despite
>> Apple
>> lack of support for the technology. The development cycle is OK, but
>> the
>> application itself is rather slow. I think that Java (and the Java
>> JVM) is
>> partly responsible.
>>
>> When I start the application memory usage is already around 30 Megs.
>> When I
>> go through different screen memory usage rises to 120Megs and some
>> screens
>> are very slow (fetch is rather slow on 10000+ records table at least
>> on a
>> desktop). I guess that too much stuff gets loaded into objects and
>> NSArrays
>> of Objects.
>>
>> Also there is too much processing done on the client. Our Xserve run
>> Openbase is almost idle when we test the application. I think it only
>> fetches the entire record set and pass it through to the client.
>>
>> We cannot afford performance issues. So I took this week to investigate
>> alternatives.
>>
>> So far I've tried the following setup:
>>
>> Cocoa
>> Objective-C
>> Openbase Espresso API
>>
>> Ok, this locks me in to Openbase. But we can live with that.
>>
>> I redeveloped the login screens, main menu and one screen that caused
>> me
>> problems with EOF.
>>
>> Performance is astounding.
>>
>> The applications load up at 9Meg and it does not break 20Meg despite
>> intensive usage of the complex screen. Load time is immediate.
>> Switching
>> between NSTabItems (each fetch a subset of the data) does not cause any
>> delays.
>>
>> We also found out that with the OB API some of the processing is done
>> by the
>> server. We are pretty sure that WHERE and SORT BY clauses are handled
>> on the
>> server and only the result set is passed back to the application.
>>
>> I wanted to share my experience with you.
>>
>> Using Cocoa-EOF is very tempting but the lack of support, lack of
>> documentation (aside from Javadocs API docs) and questionable
>> performance on
>> the desktop might steer you to consider other alternatives for
>> desktop-DB
>> apps.
>>
>>
>>
>>> From: John Spicer <email@hidden>
>>> Date: Fri, 02 Jul 2004 07:57:51 -0500
>>> To: WOdev List List <email@hidden>
>>> Subject: Cocoa EOF
>>>
>>> We were warned away from this (by Apple) because they said it was
>>> going
>>> away. As a result, we didn't spend much time looking at it.
>>>
>>> Is it a two tier or three tier? If it's three tier I have to admit I'm
>>> tempted again....web services is poorly documented!
>>> _______________________________________________
>>> webobjects-dev mailing list | email@hidden
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>>> Do not post admin requests to the list. They will be ignored.
>> _______________________________________________
>> webobjects-dev mailing list | email@hidden
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>> Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.