Cocoa and ODBC

Its being a long time I have not come here to write... and it has been a long journey since a nice tool come to the desktop to connect a relational database with Cocoa (inside OSX). Since the introduction of the Core Data framework, some years after the deprecation of Objective-C version of EOF, it became a bit of a nightmare to connect an app to a Relational Data Base (as may be Sybase or Oracle)... some attempts to rewrite EOF has been done, e.g. in Alex' Open EOF by Martin

The aim of this new attempt is to use the following mixture: The Odbc Framework is a Cocoa framework providing access to ODBC data sources. It works on top of the iODBC Framework which is a widely portable C-oriented framework that follows the ODBC specification (Open Database Connectivity). The Odbc Framework includes a Cocoa Core Data Persistent Store for Odbc, which will be used here. And finally, we will use as persistence the proposed database Mimer SQL  (: which has a free version for developers :)

Alex's EOModeler

The good news about AJRDatabase is that the compiled version at SourceForge simply runs on Leopard. For, simply copy the EOModeler application to your ~/Developer/Applications folder, the AJRFoundation, AJRInterface, EOAccess and EOControl frameworks to your ~/Library/Frameworks folder, and the Postgres eoadaptor to your ~/Library/Database Adaptors folder... if you have a running Postgres database, you will be able to connect and reverse engine it after double-clicking on Alex's tool.

Nice work!!!

Now I will need to find or develop a Sybase eoadaptor... I hope it is not another nightmare...

So far, no good solution

Long time with out writing... but I had not found nothing, good enough, to bring back EOF to the Desktop.
Andrew Lindesay claims that he is developping his own JSON-RPC to this end, but I had not found it easy to use, and, to be honest, I am not sure it is "the right way"; but, if you want to give it a try, go to lindesay.co.nz.

The main obstruction, so far, to substitute Cocoa EOF with WO Services has been that I had not found how to publish an EOEditingContext easily... let us try again...

What's NeXT?

The next step to successfully use Web Services to substitute Cocoa EOF is to publish into a service an EOEditingContext. In this way, Core Data should be able to use EOF, via those services offered by the Editing Context, as a persistence media.

I am not quite sure where to put the line (the service); on top of the Editing Context? or, even below it?
To transfer Enterprise Objects? or, shall I transfer Dictionaries?... it will depend in the performance... we will see.

By the moment, the idea is to have, in the server side, the persistence mechanisms offered by EOF; and in the client side, a Cocoa app running Core Data to manage Display Groups and all the consistency necessary in a complex db-model. For, the model will have to be duplicated in the two formats: .eomodeld and .xcdatamodel ...

... welcome to a new nightmare!

On Java & Objective-C

The main source of Objective-C frameworks is Steve Jobs and his team. They started to use this language since they were selling the NeXT machine. When NeXT buys Apple (for a negative amount of money ;^) they recompiled the operating system OpenStep to run into Apple's hardware; since then, it is know as Mac OS X. These are all old news. One more: Java becomes fashioned more or less in the same time — a bit before, to be more precise.

NeXT was forced to move one of its most valuable pieces of software, WebObjects, from Objective-C to Java; but they wanted to keep it "native" inside OS X... so, they coded the so called Java Bridge, a (never too nice, but useful) piece of software which allows to communicate the JVM and the Obj-C runtime. With this tool at hand it is possible to code (to develop) applications which have the beauty interfaces (and useful) frameworks of Cocoa (the front-end of OS X) and have also all the database connectivity developed for WebObjects, the so called Enterprise Objects Framework. The result: the best client/server apps in the market.

The bad news (well, not so new) is that Apple is giving up on the Java Bridge... this means that I will have to port all my code to use something else in order to provide nice and useful interfaces to my users, while keeping the database connectivity easy to manage... not an easy task, but it has to be done =:o(