..with its Spotlight®.
See 'SQLite Support' and 'Core Data Framework' here: http://www.appleinsider.com/article.php?id=593. That's not entire KexiDB but always looks like interesting competition.
They seem to be big on meta-data and all that fun stuff, the intent seems to be different. To be honest, I haven't kept up with Kexi at all, can it be a facilitator (hopefully in a big way) towards similar goals, the meta-data holy grail?
It'd be nice to see people clue in and see Hans has the right idea, information is useless without recall and power batch operations; without a powerful and fast meta-data system, we're going to be left behind it seems. I'm not big on the VFS, it's a bloat layer, rather than a nice abstraction.
I mostly mentioned about their use of SQLite. They are large player after all. And mostly agree that metadata is not a remedy for all user search problems.
We should only hope they won't close SQLite code. What do you think?
Well so long as it doesn't hinder profitability it'll be open. That's the problem with Apple's OSS "love", they're a bit virial in that regard. Mind you, it's the same action, for different motives, as GPL. In both cases you're protecting a community/entity, the difference being why and whom.
As for SQLite in particular, I think since it'll become rather fundemental, there will always have to be exposure at the API level, the thing is if you look at OSX's architecture and then overlay what parts of it are OSS, then it gets interesting. Take the Kernel, the core of which is open. However, go up a level and not much at that and you run into the proprietary stuffs. This includes their stuff with HFS+, Quartz, Aqua, Java and so on which they feel is rather key to their platform, in partuclar the Mac experience. Now the question is where does SQLite fit into their architecture. With that tidbit you can easily figure out whether it's going to be open or not, going by a trend in that OSX seems to be abstracted along closed/open layers -- at least that's what I've observed. As for things like Rendevous, which might seem like a counter-arguement to this, aren't. AFAICS, it's not a core feature to the Apple experience, it's more like a core interface/seeding feature and when it comes to interfacing Apple is open so long as it doesn't attack the experience they wish to convey.
By seeding feature I mean something that can be used in other, say OSS efforts which due to APL will allow Apple to swallow more code on the cheap.
Personally, I never bought into this OS X hype. It's ok, and that's if you're being nice. Their UI overall is pretty good, but there is a fair bit of things I find wanting in terms of specific apps. Then there is the fact that it tries to sell you something every 10 seocnds. But this is me just ranting. ;)
Thanks for you thoughts. Another funny issue for me is: which SQLite engine we'd use for Kexi OS X port (no, it's not yet ported) - the one bundled with OS X (hmm, but it's not present on 10.2 and 10.3, right?) - or the one bundled with Kexi (aha KexiSQL, i.e. system-independent and being tweaked a bit for our needs).
It depends, I'm pretty sure Apple's SQLite will be lightning fast on their platform, so that's something to seriously consider. Maintaining your own tweaked engine could get costly interms of development effort -- I'm not sure how that's working out for the current group.
You might wanna have a quick look at Konfabulator, they might either roll their own engine or perhaps Apple's already done their leg work and it's just a front-end app that Apple is rolling out in their next OSX release.
Maintaining your own tweaked engine could get costly
Really not. The tweak is really minor. Btw, Apple's OS continues the tradition that's opposite to Linux: for average joe user many things are still packaged as bundles, so I suppose, additional ~100KB lib should not be a shock for Mac lovers :)
This place is a blogging platform for KDE contributors. It only hosts a fraction of KDE contributor's blogs. If you are interested in all of them please visit the agregator at Planet KDE.