metakit graph storage

[Stanislav Karchebny]

Probably we could take a look into this: http://e4graph.sourceforge.net/

Since we're going to introduce metakit into kdelibs for akregator at some
point, it wouldn't be too much overhead to use it (its lightweight anyway).

The only issue there are no SQL queries (only a python SQL interface an Tcl
ODBC wrapper), but who knows... kexi guys are always around.


..just a random nightly thought..
--
keep in touch. berkus.

Roey on #kde-devel: when I hear best of breed I tune out--it's too much a
buzzword. What I carry between my legs is best of breed. And like KDE, just
because it's less visible doesn't mean it gets less usage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050212/80ac04eb/attachment.pgp

[Aaron J. Seigo]

Post by Stanislav Karchebny
Probably we could take a look into this: http://e4graph.sourceforge.net/

having had a look through the documentation i don't know how useful it would
be to us. it solves the most trivial aspect of the problem, though it does it
with some style. we'd still have to provide Qt wrappers for it (both for data
types and for it's IMO ugly use of callbacks), write a backend that isn't
metakit (so we can have concurrent and network access) and provide a way to
associate and search larger blocks of data like full text vectors to it, and
we'd still have the other 90% of the project let to tackle. i'd rather just
build on top of Qt SQL for now and make something that stands well integrated
and purpose built. in fact, i think it will be faster, more efficient and
produce a better API to implement this bit ourselves.

Post by Stanislav Karchebny
Since we're going to introduce metakit into kdelibs for akregator at some
point, it wouldn't be too much overhead to use it (its lightweight anyway).

into kdelibs? did i miss a discussion on kde-core-devel about this?
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050212/03bab564/attachment.pgp

[Stanislav Karchebny]

that stands well integrated and purpose built. in fact, i think it will be
faster, more efficient and produce a better API to implement this bit
ourselves.

Well, you are right *too*. :)

Concurrent/network access is not well inside metakit as its a one-app-library,
but i think we will handle access to klink database through
klink{libs,daemon} for network access anyway, or am I wrong here?

Post by Stanislav Karchebny
Since we're going to introduce metakit into kdelibs for akregator at some
point, it wouldn't be too much overhead to use it (its lightweight anyway).

into kdelibs? did i miss a discussion on kde-core-devel about this?

Nope, you didn't. We want to make it up and running first before discussing
its pros and cons. Thats why *at some point* is written there.
--
keep in touch. berkus.

Roey on #kde-devel: when I hear best of breed I tune out--it's too much a
buzzword. What I carry between my legs is best of breed. And like KDE, just
because it's less visible doesn't mean it gets less usage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050212/348f9c21/attachment.pgp

[Aaron J. Seigo]

Post by Stanislav Karchebny

that stands well integrated and purpose built. in fact, i think it will
be faster, more efficient and produce a better API to implement this bit
ourselves.

Well, you are right *too*. :)
Concurrent/network access is not well inside metakit as its a
one-app-library, but i think we will handle access to klink database
through
klink{libs,daemon} for network access anyway, or am I wrong here?

It remains to be seen how network access will be done, but it seems the most
natural location for the actual network traffic to be handled would be at the
storage layer. Perhaps not, though, we'll have to see.

Concurrent access is another "must have" though, and writing our own daemon to
handle the necessary ACID nature of databases when you start talking
concurrency isn't something I personally relish writing. ;)

Looking at the API further, there's just a lot of expressivity missing that
we'll need. It looks really great for storing and traversing meshes of data,
but that's really just the one small part of it all. Maybe we'll find
something yet; nothing wrong with considering using code that already been
written if it will end up saving us time/effort.
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050212/aac17f5d/attachment.pgp