metakit graph storage

[Aaron J. Seigo]

On Saturday 12 February 2005 09:11, Stanislav Karchebny wrote:
> On Saturday 12 February 2005 16:41, Aaron J. Seigo wrote:
> > 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