Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
C++ Prolog
branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
rpm
src
tests
.gitignore
README.rst
common.pri
coverage.pri
makedist
org.nemomobile.events.EventFeed.xml
project.pro

README.rst

Overview

The eventfeed package provides

  1. eventfeedd daemon which is responsible for:
  • registering the D-Bus service org.nemomobile.events.EventFeed,
  • event storage maintenance,
  • emitting signals upon adding or removal events from the storage.
  1. trivial wrapper library (libmeegotouchevents) around a proxy to org.nemomobile.events.EventFeed. This library serves as public API.
  2. QtQuick component listening to signals from the D-Bus service and updating component's view.
  3. libeventfeed used by eventfeedd and by the QtQuick component to deal with event storage.

In order to decrease startup time the QtQuick components initializes its view by loading event items from the storage directly.

Event storage

eventfeed uses SQLite database as a storage for event items. Its schema is very similar to what's been used in MeeGo Harmattan:

CREATE TABLE events (id INTEGER PRIMARY KEY, title TEXT, body TEXT,
                     timestamp TEXT, footer TEXT, action TEXT, url TEXT,
                     sourceName TEXT, sourceDisplayName TEXT);
CREATE TABLE images (id INTEGER, position INTEGER, originalPath TEXT,
                     type TEXT, PRIMARY KEY(id, position));

Notes

If we decide not to use any D-Bus based thumbnailer, but to rely on the QML plugin then this separate daemon providing org.nemomobile.events.EventFeed service may be considered an overcomplication. Instead the service might be a part of the QtQuick component and the API library might be rewritten to update the event storage directly.

So instead of:

                                                      --> event model 1
                                                      v
client -> dumb library -> dbus -> event service -> dbus <-> event model 2
                                                      ^
                                                      ---> event model 3

the scheme might look like this:

client -> smart library -> dbus -> single event model

OTOH if go this way then

  1. event feed bindings for other programming languages will get complicated,
  2. changes in one event view won't be reflected in all others given that we want to allow running many event veiws in different processes at once.

The field events.action seems to be redundant.

Something went wrong with that request. Please try again.