Re: Finding and Reminding, tech issues, 3.0 and beyond

[Martyn Russell <martyn lanedo com>]

On 10/04/10 22:10, Owen Taylor wrote:
> On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote:
> > On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor 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.

I don't think this is such a bad thing. What other choices are there? 
understanding how to extract the metadata from a specific file yourself 
or understanding SQL to talk directly to a database? At least SPARQL is 
something in between which provides the right level of power without 
exposing the DB.

> The reason I consider storage relevant is that throwing data into "an
> optimized SQL database" where you don't have any ability to control what
> is indexed or understanding how query plans are executed is usually a
> recipe for application performance disaster. There are many people who
> make an excellent living going in and fixing these sorts of application
> performance disasters.

Do you have a case where people would need to control what is indexed or 
need to understand how query plans are executed?

We are happy to work with applications on improving this of course.

> 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.

This will always be the case. Since 0.7 came out we have been helping 
people fix their queries. It would be no different if people used SQL 
directly to the database.

We are currently working on bolstering this area so slow queries can not 
cause performance issues for other applications so easily.

--
Regards,
Martyn