< Projects | Nepomuk Revision as of 19:30, 29 August 2011 (view source)Trueg (talk | contribs) (→Git Repositories)← Older edit Revision as of 14:35, 30 August 2011 (view source) Trueg (talk | contribs) Newer edit → Line 54: Line 54: * For now we drop the facet API and move it to playground since it was forced and is weird * For now we drop the facet API and move it to playground since it was forced and is weird * We drop all in kdelibs/nepomuk/ui from public API and only copy what we need for the metadatawidget * We drop all in kdelibs/nepomuk/ui from public API and only copy what we need for the metadatawidget +* We will drop ResourceManager as a public class. +* We will drop QueryServiceClient and replace it with methods in the Nepomuk namespace that return job instances which will then signal the results. === Queries === === Queries === Revision as of 14:35, 30 August 2011 Contents 1 Topic 2 Items of Discussion 3 Participants 4 Decisions 4.1 Git Repositories 4.2 Libraries 4.2.1 New Libraries 4.2.2 API to drop 4.3 Queries 4.3.1 Ideas Topic For KDE 5.0 kdelibs and kde-runtime will be split into several parts/components/repositories in order to be more modular and reach a larger audience. This development is at the moment going on in the frameworks branch of kdelibs. There is basically three groups of repositories: Tier 1: components which only depend on Qt and no other lib/component from KDE Tier 2: components which depend on Qt and other libraries from Tier 1. Tier 3: components which depend on anything Due to our central runtime parts basically all our components are in Tier 3. The only exception is Soprano which is in Tier 1. The goal of this meeting is to determine what to do with Nepomuk in KDE 5. Items of Discussion How do we split libnepomuk for kdelibs 5.0 Which parts do we drop (besides the already deprecated API) Which new parts do we introduce (candidate: nepomukdatamanagement) and how do we combine them with existing libs (maybe merge) What do we do with ResourceManager::mainModel()? Do we drop it altogether? Do we introduce an alternative which is purely DBus based? Do we extend the QueryServiceClient to provide better SPARQL result support? We need to move nepomuk-dependent code from KIO to our libs We need to make the rest of KIO independent of Nepomuk. This is mainly the download tracking. David Faure suggested to introduce a DBus signal which one of our services can connect to. Maybe similar to the KDirNotify signals. Participants Vishesh Handa Artem Serebinsky Sebastian Trueg Decisions Git Repositories Which repositories will we use and which components will they contain. The decision was based on the question of which parts of Nepomuk we want always to be available and which are optional. nepomuk-core - The main Nepomuk repository which is required in any case and provides the basic Nepomuk functionality including storage, query, and the like. Draft repository can be found in trueg's nepomuk-core scratch repo. Nepomukserver nepomukservicestub Extension ontologies Core services: Storage/DMS, Query service, Filewatch service, File indexer Core libraries: see below. nepomuk-ui UI libraries: see below nepomuk-kde-kio KIO slaves: nepomuksearch, timeline, nepomuk nepomuk-kde-config-ui nepomukcontroller Nepomuk KCM Libraries New Libraries Which libraries do we want to have in the end? nepomukcore - The core libraries which are always installed and everything else depends on libnepomukdatamanagement The current kdelibs/nepomuk/core The current libnepomukquery The current kdelibs/nepomuk/types Nepomuk::formatPropertyValue - maybe rename to propertyToString to indicate that it is the basic formatting method nepomukui - UI elements build upon nepomukcore The current kdelibs/nepomuk/utils/searchlineedit.h/.cpp, searchwidget.h/.cpp KFileMetaDataWidget - with a new name and in Nepomuk namespace (is in dire need of a rewrite) API to drop For now we drop the facet API and move it to playground since it was forced and is weird We drop all in kdelibs/nepomuk/ui from public API and only copy what we need for the metadatawidget We will drop ResourceManager as a public class. We will drop QueryServiceClient and replace it with methods in the Nepomuk namespace that return job instances which will then signal the results. Queries We currently have the async QueryServiceClient API and the sync Soprano APi provided through ResourceManager::mainModel. The goal is to have one way to query Nepomuk in order not to confuse developers. This one way should allow for use of Nepomuk::Query::Query or a SPARQL string. The result type would depend on the query method used - for SPARQL strings it should return bingings, for Query instances it should return something simpler like Nepomuk::Query::Result. Ideas Drop the mainModel method Drop QueryServiceClient and instead add query methods into the Nepomuk namespace which return jobs or query instances that provide result signals and can be synchronously iterated with a method like waitForNext. This method would ideally not use a local event loop but wait for the socket to give more information. Merge Query service into storage service for faster queries Unless kernel DBus is finished quickly we should keep the socket communication for queries. Otherwise the DBus daemon goes crazy. Retrieved from "https://community.kde.org/index.php?title=Projects/Nepomuk/Irc_meeting_nepomuk_frameworks&oldid=14661" Content is available under Creative Commons License SA 4.0 unless otherwise noted.