Please let me attempt to clarify a few things. Mention was made to the
Cocoa EOF Runtime Preview Evaluation License available here:
http://developer.apple.com/mkt/swl/agreements.html#cocoaeof. Please
ignore this document. It is historical in nature and won't be there
much longer.
The only legal agreement that applies is the WebObjects Software
License Agreement that is included with your WebObjects software. This
agreement doesn't specifically preclude Cocoa-Java-EOF. Feel free to
use the technology under the terms of the license agreement.
A very valid question was asked:
Re: Cocoa and java and EOF
| Is this development path viable or am I cornering myself?
The Cocoa-Java-EOF technology, as it exists today in WebObjects, is not
being moved forward. The feedback from customers has been "make
WebObjects more standard and more interoperable with industry
standards". Achieving these goals will have higher priority with
engineering, QA and documentation than Cocoa-Java-EOF.
Having said that, if you can live with any limitations and the fact
that things may change, Cocoa-Java-EOF may work well for you. In the
end, only you can decide.
May I humbly make a suggestion ? The iTunes Music Store uses
WebObjects and EOF in the back end of the store, a native client on the
Mac (and Windows) and passes XML down the wire. There are a number of
XML technologies in WebObjects. You could use SOAP, or roll your own
XML protocol as iTMS does. You would still have EOF for database
connectivity, the full power of Xcode/Cocoa/IB on the client and you
could change the client and server independently.
Bob Fraser
_______________________________________________
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.
