Re: [Tracker] Recommended Update Policy

[fr33domlover <fr33domlover mailoo org>]

Thanks! I'll try to batch them then. And your idea for Tomboy is
interesting, it is a similar case to what I have here.

I als had a more advanced idea, allow clients to specify how fast they
need certain data (e.g. update in real-time or it can wait a minute, for
example mail probably could wait a minute while some real-time data
would have to be updated ASAP), and decide how frquently to send data
based on these choices of clients.

Anyway that's just optimization, I don't need it right now. Batching
should be enough.


Thank you!

On ב', 2013-11-18 at 09:35 -0800, Ivan Frade wrote:
> 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
> _______________________________________________
> tracker-list mailing list
> tracker-list gnome org
> https://mail.gnome.org/mailman/listinfo/tracker-list