On Wed, 5 May 2004, WebObjects wrote:
> 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.
Yay. :)
So, basically, the cost of deploying to other customers is the cost of the
license for doing WO-EOF. That sounds fine.
> 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.
I wish it were, but one of the reasons I didn't use it for a pet project
was quite simply that it wasn't documented.
> 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.
Sometimes you need a desktop app, though.
--
_Deirdre http://deirdre.net
"Ideally pacing should look like the stock market for the year 1999, up
and up and up, but with lots of little dips downwards...."
-- Wen Spencer on plotting a novel
_______________________________________________
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.
