Michael, tir, 17 06 2008 kl. 06:49 +0000, skrev [EMAIL PROTECTED]: > Aww, Jamie didn't think it would be suitable for my blog engine, > either. :) Wasn't the plan to use Tracker for Epiphany's bookmarks and > history? Is the problem that of storing arbitrary RDF?
I have not discussed it directly with Tracker developers, but it's my impression that they don't feel that Tracker is ready to support a SPARQL interface for queries yet. > It's about complexity, and people's tendency to try to minimise it. > Using the file system is at least an order of magnitude less complex > than a service for storing your data in terms of implementation, testing > and bugfixing. Using the native model for your data is similarly less > complex than converting it to something else, as is keeping your > metadata and data together vs splitting it up. I'm still puzzled, because personally I feel that using a service is much easier than having to reinvent serializing, parsing and not least querying every time you begin a new software project? > So to be successful, something to minimise this complexity is needed - > probably some code (he says, while providing none). How are the KDE guys > doing it? They're using Soprano, but how do apps get data into it, out > of it and keep it sync'ed? What programming interfaces are available for > K developers? The Soprano server has a D-Bus, TCP and unix sockets interface for querying, and wrapping classes for the D-Bus interface are also available: http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/soprano_server_dbus.html Backend, serializer and parser plugins are developed with the Soprano libraries. http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/soprano_writing_plugins.html _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
