[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: FYI: "CoreData lite"
From: |
hns |
Subject: |
Re: Fwd: FYI: "CoreData lite" |
Date: |
Mon, 4 May 2009 23:45:54 -0700 (PDT) |
User-agent: |
G2/1.0 |
On 5 Mai, 02:00, Yen-Ju Chen <yjch...@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Dirk Theisen <d.thei...@objectpark.org>
> Date: Tue, May 5, 2009 at 12:06 AM
> Subject: FYI: "CoreData lite"
> To: cocotron-dev@googlegroups.com
>
> From: Ken Case <K...@omnigroup.com>
> Subject: FYI: OmniDataObjects
> To: e...@omnigroup.com
> Date: 4. Mai 2009 16:49
>
> Hi, all, it's been a while!
>
> We still use EOF for one of our internal projects (OmniBugSnacker), but
> as you all know it's getting a little long in the tooth. (It gets
> harder and harder to keep it limping along with each OS
> upgrade--really, it's amazing that it still works at all on Leopard
> after so many years and an architecture switch.)
>
> For OmniFocus, we decided to try CoreData since we didn't need to store
> our database on a central server. (Setting up a central server to hold
> your data is a hard sell for a consumer app anyway.) It works
> reasonably well for that purpose, and certainly has a more modern API
> than EOF! When we decided we needed to be able to synchronize that
> data, we recorded the CoreData transactions (insert, update, delete) as
> XML and sent them to a WebDAV server where other clients could read
> them and apply the same changes. Now, this doesn't exactly replace
> EOF, but it does have some advantages: you can access your data
> offline, and synchronize it on your own schedule (through notifications
> or on your own schedule or on demand).
>
> Anyway, the reason I mention all this is because when we ported
> OmniFocus to the iPhone last year, we were surprised to find that it
> didn't have CoreData yet--so we ended up writing the pieces we needed
> and releasing them as the OmniDataObjects framework, which we released
> as open source under an MIT license. Some of those pieces might be
> useful in other contexts; since it's all under an MIT license, you're
> welcome to grab whatever bits you find useful and use them however you
> like.
>
> All of Omni's open source frameworks are now published through github
> (you'll find a link to them at <http://www.omnigroup.com/developer/>),
> and if you want to talk about OmniDataObjects further it has its own
> mailing list (nearly as quiet as this one!) at
> <http://www.omnigroup.com/mailman/listinfo/omnidataobjects>.
>
> Cheers,
> Ken
> _______________________________________________
> EOF mailing list
> E...@omnigroup.comhttp://www.omnigroup.com/mailman/listinfo/eof
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Cocotron Developers" group.
> To post to this group, send email to cocotron-dev@googlegroups.com
> To unsubscribe from this group, send email to
> cocotron-dev+unsubscribe@googlegroups.com
> For more options, visit this group
> athttp://groups.google.com/group/cocotron-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
> --
> Yen-Ju Chen
> Sent from Hsin-Chu, Hsz, Taiwan
Interesting. Thanks for the link.
I looked a little into it:
"OmniDataObjects provides a CoreData-like API, but with a much smaller
feature set"...
Then, I counted their number of source files and came to 51. Our
GSCoreData has just 31. So I am not sure what they have done but I
would say it is just the n+1st SQL wrapper library with different API.
I would prefer an API compatible to Apple CoreData.
So we need volunteers to work on GSCoreData and finalize the missing
parts! I think 80% is already there - thanks to Saso. DataBuilder
already works.
Nikolaus