Another weird backtrace related to cover drawing

[Daniel Winter]

On Wednesday 23 July 2008 08:33:42 Maximilian Kossick wrote:

> I think it's not a good idea. There's no reason to use querymaker in a
> synchronous manner in libamarok. Regarding scripting, is there any
> relevant scripting language that is not able to use callbacks?

There are use cases for doing sync querys.  In a lot of cases were the actual 
work is already done in some worker thread it is extra work to use the async 
event driven QueryMaker without any benefits. Or even worse with extra overhead 
of creating a new thread (not big but anyway) and the event handling.  

More complex code to write and more complex code to maintain. In the longterm 
more bugs. 

And if that BQ is that useless, why did Nikolaj use it again in in a commit 
from today? (for the CurrentEngine data engine for the context view)

Also Daniel (the biased playlist one ;-)) is using BQ.

And for the scripts.  Sure I think all languages supports callbacks. 

But for some easy scripts (and scripts are in a lot of cases easy smaller 
jobs)  I think it would also be very helpful to have a sync way of doing 
querys.  Why using the event  based with extra thread if you does not need it. 
Just to make it harder to use it and create an extra thread (amarok already 
creates  a lot of threads (there are often 14 of them hanging arround))?

So I am all for having a way of doing sync querys. Just by saying the 
QueryMakers "i want next query blocking" it will then not create a new thread 
and doing the work there. 

We could even easly port the BlockingQuery (also I do not see the need for 
that then) port to the "new" Api. 

I would do the work for the Nepomuk QueryMaker and if no one else want to do 
it for theSqlQueryMaker. The others (MemoryQueryMaker)  I do not know enough 
to do it.

> regarding spreading sql/sparql queries all over the place...all
> classes in a collection/service plugin are tightly coupled to each
> other. There's no reason that repcaling BlockingQuery in those plugins
> would result in query language statements all over the place...the
> easiest way i can think of off the top of my head is to provide a
> method accessible only within the plugin that allows access to the
> completed query.

May work for SQL, but not for Nepomuk QueryMaker (and others which do  not 
even work with some query language) . SPARQL is not good enough to do all I 
want to do. So i will bring probably  bring lucene querys and and some own 
result processing into it. 

So there is not someting like get query from QueryMaker and execute it by 
myself to make an sync query.   Just using QueryMaker (which already do the 
needed things) blocking would help.   

DanielW