Re: Finding and Reminding, tech issues, 3.0 and beyond
- From: "Zeeshan Ali (Khattak)" <zeenix gmail com>
- To: Owen Taylor <otaylor redhat com>
- Cc: gnome-shell-list gnome org, desktop-devel-list gnome org, jamie mccrack gmail com
- Subject: Re: Finding and Reminding, tech issues, 3.0 and beyond
- Date: Sun, 11 Apr 2010 19:30:51 +0300
Hi,
On Sun, Apr 11, 2010 at 12:10 AM, Owen Taylor <otaylor redhat com> wrote:
> Well, certainly tracking and indexing file metadata doesn't *require*
> anything as complex, or general purpose as RDF. I have some concerns
> about the complexity, but as long as we don't get to the point where
> understanding RDF and ontologies is a prerequisite for developing a
> GNOME app, we're probably fine.
In order to achieve this goal, Tracker will have to provide APIs
specifcally tailored for specific purposes. The only hurdle there is
that Tracker developers seem to be very insistent on Sparql to be
*the* API every application should be using to communicate with
Tracker. I would really love to be wrong about that but thats the
impression I got when trying to convince Tracker guys to implement the
MediaServer[1] API.
> But if we go beyond that and start encouraging people to start putting
> all sorts of application data into Tracker and relying on Tracker to do
> efficient queries on it, then it definitely is a concern. Based on how
> Tracker is mapping RDF into SQL tables, some SPARQL queries are going to
> be fast, some are going to be dead slow and people need to be able to
> come to an understanding of which are which.
I think the 'custom APIs for specific purposes' approach will
minimize such performance issues since in that case both
application(s) and Tracker will know exactly what is expected from the
very start. For example, I am using optionals in my queries in Rygel
and I observed that they make the queries very slow. I was told (by
Tracker developers) that the solution is to use property functions
instead. I haven't gotten around to change this but I am affraid it'll
require not only miner changes but some redesign of the code.
Now if Tracker implemented the MediaServer spec I mentioned, I would
have just informed Tracker guys which API is slow and it would have
been upto them to optimize it. i-e I wouldn't have needed to even know
about optionals and property functions, let alone to change/redesign
my code to make the queries faster.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
[1] http://live.gnome.org/Rygel/MediaServer2Spec
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]