On 23 Jun 2013, at 11:38, Michael Crawford <mdcrawf...@gmail.com> wrote:
>> To me, it's not that you'd have to write all the code from scratch that >> makes Core Data concerning, it's the fact that the format is undocumented. > >> If Apple published a complete specification for the format, I'd be willing >> to use Core Data, but as it is, the prospect of having >> one's own file format as a black box is a huge turn-off to me. > > > Thanks for tip, I was unaware of that. > > Sure I can see how it's nice to use the Core Data API, but one would > have to be completely out of one's tree to save end-user documents in > a completely undocumented format, even if it were cross-platform. I don't think you would have to be completely out of your tree. The precedent is encapsulation - you should not care about internal layouts, only what the API exposes it. Seems that is exactly what CD does. And I think CD does give some extra discipline in modelling things correctly and making it easy to persist things, so I think it's doing a lot for you, notwithstanding my concerns that it might be more ER than relational. Most DBMSs also do not publish their internal file formats because these can change and if the abstraction is good - completely irrelevant. Thus application programmers should be encouraged to be loose coupled on the internals of a system, only using it in the published ways. However, I can see your point that it is a concern that if Apple discontinues CD that suddenly we have a whole lot of unreadable data and really anything stored persistently should be cross-platform whether stored on disk, or transmitted across a network. But perhaps to do that, just a small utility program that uses to CD API to get the data will suffice. But it is a little like the Carl Sagan records sent out on Voyager I (I think) for aliens to enjoy - now how are they going to do that without a record player? It will be like trying to decipher the Dravidian script of Mohinjo-Daro (we got lucky with Hieroglyphics with the Rosetta Stone). Vint Cerf recently stated that we might lose a lot of data because we lose the ability to interpret it (not such a new thought - one of the threads of Godel, escher, Bach). > > I lost what would have otherwise been a really lucrative, really fun > consulting gig in which I would have been able to use my Physics > degree. I'm afraid that I made it clear to the hiring manager that I > considered him an idiot for even asking me whether I knew Core Data. > I didn't come right out and say so, but I sure did make it clear that > I considered him ill-advised. > > Just now I'm about to register a KickStarter project that would > compensate me for completely reverse-engineering the Core Data > formats. > > However I need to set a fixed price goal, as well as a finite delivery > schedule. One only gets money at all from kickstarter if both goals > are met. That kind of project estimation, in my own experience, is an > as-yet unsolved problem, not just for me but for every software > engineer. If you claim you know how to estimate software development > time and cost, I don't believe you. > > Don't even _think_ about suggesting that such reverse-engineering is > illegal. Reverse-engineer is specifically protected under the law. > > If you have some proprietary method you want legal protection for, > that's what patents are for. > > Trade secrets are used either when the invention is either not > "novel", or not "unobvious" and so not legally patentable, or when one > hopes to maintain the secret for longer than the patent's twenty-year > term, such as the secret recipe for Coca-Cola. There are only a very > few, very trusted people who know what all the ingredients are. Had > they patented it, the recipe would have been placed into the public > domain a hundred years ago. > > I know this very well. I've reverse-engineed a whole bunch of > different kinds of things. > > That resulted in a Senior Engineer position at Apple itself in the > mid-90s, where in my role as a Debug Meister for the Traditional OS > Integration team, I reverse-engineered a great many third-party > applications that were found by QA to stimulate crashes in new builds > of the Mac OS System. I worked on 7.5.2 and 7.5.3. > > For example, I once supplied Microsoft with the exact byte offset in > the Word 6 binary, at which they started a one-shot timer, then after > it fired, reset it, so it would tick continuously. Unfortunately, the > Classic Mac OS didn't have any really clear concept of a process - > some other Apple engineer once described the System as just "a bunch > of subroutines", so under a very heavy paging load, that timer would > fire well after Word's executable code had been overwritten with some > other data. > > > My very first consulting gig when I hung out my shingle in April 1998, > was to reverse engineer the Movie Magic Scheduling database format, so > that Graphical Planet's handheld devices could interoperate with Movie > Magic. Graphical Planet did ask the Movie Magic people to > interoperate with them, but they refused, so they hired me. In just > three weeks I fully documented the format, just by making lots of > databases with small variations between them, then comparing hex dumps > of pairs of them - the single letter "A" in just one field, compared > to "AB" in that same field, as well as "A" in one field, then just "B' > In some other field. I also wrote a C program that dumped a human > readable text file of the whole database. > > Graphical Planet's acceptance test was for my C program to dump the > project management plan for a full-length motion picture. Movie Magic > even had a form that enabled one to schedule the appearance of potted > plants on the set. > > If I can do that, surely I can reverse engineer Core Data. > > And yes, many of my best friends still work for Apple. I don't mean > anyone at Apple any ill-will, other than the miscreants who make such > decisions as to convince all the developers to depend on undocumented > formats for their livelihood. The people I actually met when I was at > Apple, the ones that I know that work there today, are not that way. > > Mike Crawford > mdcrawf...@gmail.com > http://www.goingware.com/ <-- Down, but back up Real Soon Now. > Portland, Oregon > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com > > This email sent to ianjoy...@me.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
