1. 8
  1. 5

    Having had the luxury of NeXT cubes at college in 1995, after a shameless tryst with Irix for a few years I followed the earlier minor obsession with NeXTSTEP through to eventually developing some medium-sized WebObjects apps. Even the Java reimplementation/bridge/wrap of Foundation in WO4+ seemed so obviously so much more mature and well-considered for actual app development than J2EE/servlets/Beans/factory hell that I still feel a bit sad that it went the way it did. Even being forced to use ProjectBuilder on YellowBox on Windows seemed somehow more palatable than the alternatives. Clear distinction in the API between mutable & concrete data structures seemed bizarre but radical to my fresh eyes; maybe the inheritance structure in the data models was a bit mad; but EOF was a thing of alien beauty, and WO’s component model was just like magic for someone used to writing CGI. Proper space-age tech, and when you think when it was written, pow.

    1. 2

      Whatever became of WebObjects? Most well loved APIs like this either survive or spawn descendants at least in spirit.

      1. 2

        CoreData apparently derives from Enterprise Objects Framework, an important companion API to WebObjects. https://en.wikipedia.org/wiki/Core_Data#History_and_genesis

        1. 2

          Yeah that’s exactly EOF. Language-independent ORM, where you define a datastore-independent (well, choice-of-RDBMS-independent) object model, and then use EOF’s built-in tools to generate the DDL to create/sync your schema. You could just press a button in EOModeler app and create a schema for a different DB, and it would just work. (Obviously depends on the adaptor but they were good.) Aggressive caching model to deal with early 90s network stuff worked well when translated to web app infrastructure. Heavy use of Foundation style key-value coding where you could represent object relationships in dotted notation strings and just deal with complex relationships through paths, both in data access and connected up to the UI in WO. Really radical for me was that you had an EOEditingContext object which was basically an in-memory scratch pad to do all your data operations, and then choose to commit, discard, or deal with DB errors (e.g. referential integrity failures) in try/catch. Change notification across app servers was kind of hard, but isn’t it always ;-)

          There’s an interesting bit of commentary on the relationship between EOF and CoreData at the Wikipedia page - it reads a bit fanboyish but it’s pretty accurate. As I understood it, CoreData was more intended for single-user Mac apps, vs the “enterprise” heritage for EOF.

        2. 1

          Apple just didn’t seem to want it on their hands anymore. First it dropped from $50k for a licence to $699, then it was bundled with OSX server, then just not available. I heard that for a long while they still used it to run the Store and still had a lot of WO developers in-house, but who knows when it really came out of use behind the curtain.

          There was an open-source project to reproduce WO - it seemed to get somewhere with Eclipse integration but the “new web” with sensible URLs and REST kind of left it behind. Cayenne was an effort to reimplement EOF APIs which seems to have been incorporated but I don’t know where the whole thing ended up tbh.