Re: [Tracker] Recommended Update Policy

[Ivan Frade <ivan frade gmail com>]

Hi,

 In general, batching updates is a good policy, at least to save DBus traffic and avoid unnecessary noise in the system.

 The application knows how the data is presented and modified, It should group the changes in a coherent state and then send them to Tracker in an async fashion. No need to block the UI.

 For example,  If you are changing properties in a preferences window, send the results when the user press "close". If the changes happen while editing (like writing in Tomboy), you could set a timeout after stop typing. Writing (even async) per small editing is a lot of flow between app and tracker, with not real value.

 I think there is no more advance pattern for this. In this regard, tracker is not different from any other DB.

 Hope this helps,

Ivan

On Sun, Nov 17, 2013 at 3:42 PM, fr33domlover <fr33domlover inventati org> wrote:

Hello,

Assume I have a editor application which allows a user to change object
properties. Each property value is a value in an RDF triple stored in
Tracker. What would be a good usage pattern:

1. Send UPDATE requests for specific properties every time a value is
changed by the user through the GUI, and let Tracker execute them async

2. Collect changes and send them periodically as a batch in one request
which changes many objects/properties

3. Some other known good pattern?

In the case of apps with a Save button, clearly the way is to send a
SPARQL request when Save is pressed. But for cases where the app
automatically handles saving, I wonder which approach is faster /
recommended.

-- fr33domlover

_______________________________________________
tracker-list mailing list
tracker-list gnome org
https://mail.gnome.org/mailman/listinfo/tracker-list