Re: Core Data Reverse Engineering KickStarter Project

2013-06-26 Thread Richard Somers
Just curious. Which Core Data document format are you trying to reverse engineer: XML, binary, SQLite, or all of them? Richard Somers On Jun 25, 2013, at 8:31 PM, Michael Crawford wrote: > Take a guess at the document format. > Write an importer that reads that format. > Put assertions everywh

Re: Core Data Reverse Engineering KickStarter Project

2013-06-25 Thread Michael Crawford
On 6/25/13, Scott Ribe wrote: > This is what I've been thinking--with the importer asserted to a crazy > extent, so that you get notified of anything that it doesn't completely > understand. Using assertions in an importer is one of my more-effective reverse engineering techniques. Take a guess

Re: Core Data Reverse Engineering KickStarter Project

2013-06-25 Thread Jens Alfke
On Jun 25, 2013, at 10:47 AM, Wim Lewis wrote: > FWIW, Omni's open-source data objects framework was our response to our > difficulties with CD. It doesn't do everything CoreData does, and it does > some things CoreData doesn't, but if you're considering taking this route, > you might be inte

Re: Core Data Reverse Engineering KickStarter Project

2013-06-25 Thread Wim Lewis
On 25 Jun 2013, at 7:44 AM, Steve Sisak wrote: > The safest thing to would probably to be to implement a Core Data "workalike" > with a documented database schema and possibly an importer for "real" code > data files. FWIW, Omni's open-source data objects framework was our response to our dif

Re: Core Data Reverse Engineering KickStarter Project

2013-06-25 Thread Noah Desch
Using coredata with a documented format should probably be accomplished with an NSIncrementalStore subclass rather than trying to reverse engineer the existing undocumented format. Noah Desch On Jun 25, 2013, at 11:30 AM, Scott Ribe wrote: > On Jun 25, 2013, at 8:44 AM, Steve Sisak wrote: >

Re: Core Data Reverse Engineering KickStarter Project

2013-06-25 Thread Charles Srstka
On Jun 25, 2013, at 9:44 AM, Steve Sisak wrote: > At 8:52 PM -0500 6/22/13, Charles Srstka wrote: >> 2. Since the format isn't published, there's no reason that Apple >> might make changes to it in the future, > > I think you'll find that the reason Apple doesn't publish some > specifications

Re: Core Data Reverse Engineering KickStarter Project

2013-06-25 Thread Scott Ribe
On Jun 25, 2013, at 8:44 AM, Steve Sisak wrote: > The safest thing to would probably to be to implement a Core Data "workalike" > with a documented database schema and possibly an importer for "real" code > data files. This is what I've been thinking--with the importer asserted to a crazy exten

Re: Core Data Reverse Engineering KickStarter Project

2013-06-25 Thread Steve Sisak
At 8:52 PM -0500 6/22/13, Charles Srstka wrote: 2. Since the format isn't published, there's no reason that Apple might make changes to it in the future, I think you'll find that the reason Apple doesn't publish some specifications is specifically so they CAN change them w/o breaking 3rd part

Re: Core Data Reverse Engineering KickStarter Project

2013-06-24 Thread Ian Joyner
On 23 Jun 2013, at 11:38, Michael Crawford 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 C

Re: Core Data Reverse Engineering KickStarter Project

2013-06-24 Thread Jeffrey Oleander
On 2013 Jun 24, at 06:10, Michael Crawford wrote: Scott, How do you do it? Honestly I want to know. The best I've ever been able to come up with is that if someone always writes the same kind of code, say repeatedly writing eCommerce sites for different clients, then they can base an estimate

Re: Core Data Reverse Engineering KickStarter Project

2013-06-24 Thread Michael Crawford
Scott, How do you do it? Honestly I want to know. The best I've ever been able to come up with is that if someone always writes the same kind of code, say repeatedly writing eCommerce sites for different clients, then they can base an estimate for a new project on experience with past project.

Re: Core Data Reverse Engineering KickStarter Project

2013-06-23 Thread Scott Ribe
On Jun 22, 2013, at 7:38 PM, Michael Crawford wrote: > If you claim you know how to estimate software development > time and cost, I don't believe you. I do, and I do *very* well at it. But I certainly cannot estimate reverse-engineering an undocumented format; it would be madness for anyone to

Re: Core Data Reverse Engineering KickStarter Project

2013-06-22 Thread Kyle Sluder
On Jun 22, 2013, at 7:58 PM, Michael Crawford wrote: > > In less than ten seconds it asked which of four street addresses in > lived at, in Owl's Head, Maine. While I did live in Owl's Head back > in the day, there were very, very few people who knew my street > address. KickStarter also knew

Re: Core Data Reverse Engineering KickStarter Project

2013-06-22 Thread Michael Crawford
OK this is really creepy. KickStarter has the reasonable requirement that one verify one's identity. So I entered my first and last name, my real birthday - which I never post online _anywhere_, so as to avoid identity theft, and my present home address, which no one at all knows about because I'

Re: Core Data Reverse Engineering KickStarter Project

2013-06-22 Thread Michael Crawford
Oopsy-Doodle. I'll look into what Cocotron and GNUStep have done before actually launching my KickStarter Project. Just about their very first requirement is to state one's funding goal and time deadline. I just took a wild guess and specified thirty days, and twenty thousand dollars. That migh

Re: Core Data Reverse Engineering KickStarter Project

2013-06-22 Thread Charles Srstka
On Jun 22, 2013, at 8:38 PM, Michael Crawford wrote: > Just now I'm about to register a KickStarter project that would > compensate me for completely reverse-engineering the Core Data > formats. I believe that some of the work on this has been done already; Cocotron and GNUStep both seem to hav