I know Benjamin will hug you right now, but let's face one thing: queries may
suck for applications, but they totally rock for peer elements. Thread safety
and scheduler suckiness aside, they do actually work. Even across a queue.

I don't know of a single non-hack solution where queries are used. In fact I can
only come up with the oggdemux hack of using queries in the hope that the peer
element is one of our own elements.

Just out of curiosity, I've grepped the gstreamer core and gst-plugins code for
queries that are not GST_QUERY_POSITION or GST_QUERY_TOTAL (those could be done
with buffers or events instead of with queries IMHO). 

Results:

 - GST_QUERY_LATENCY:
   Only implemented by osssink and alsasink. Could be replaced with
   a canonically named property, or a message on the new bus or so,
   if it is needed at all (is it?)

 - GST_QUERY_JITTER:
   Not used anywhere

 - GST_QUERY_START and GST_QUERY_SEGMENT_END:
   There are two elements where this is used: fakesrc and cdparanoia
   (cdaudio claims to support this but the query function doesn't
   implement it). In the cdparanoia case this stuff can be ditched
   altogether IMHO, which leaves fakesrc. 

 - GST_QUERY_RATE:
   Not used anywhere

Similarly, grepping for gst_query_type_register() also doesn't yield any results.

It seems to me that only GST_QUERY_TOTAL and GST_QUERY_POSITION are really used
and useful in the real world - am I missing something? 

Cheers
 -Tim

I have a custom query-type 'cache' locally, which gets the contents of queue.
Using properties instead of queries is totally not-done, properties are for
user-settable and interesting things such as a bitrate or so, not for technical
stuff that the app should display right in the primary display.

If you've got a better way than queries and it's not properties, I'm fine with
it. ;).