>
>> But surely in that case then you have the tooltip
appear immediately
>> saying "Requesting..." which changes to
the client version once its
>> received.
>
> It did, and I still got the bug report from six
different people. I'm
> not necessarily saying this is the wrong way to do it,
but sharing a
> data point from actual experience with end-users
relating to this
> behavior.
>
> (And if we feel that only querying on-demand when a
tooltip needs it
> and sticking to iq:version for that /is/ the right
behavior, I'd argue
> we should then document it as a best-practice XEP.
Otherwise, people
> who haven't watched this thread /will/develop clients
that do version
> floods because 'that way I get all the data ahead of
time' or
> something similar.)
Ah ok, then I think these "bug" reports are
probably just that they are
used to it working a particular way, I would have just
notified them
this is new intended behavior and closed the bug report ;)
But yes we do need to get some consensus on the best
practice for this,
I think the best way to start is to document everywhere the
version/os
is needed and why and see if an on-demand query solves these
use cases,
if we can be satisfied that it does then iq:version should
be fine, in
my client the client friendlyname/version/os are all on
demand when
looking at a detailed property view of the contact.
>
>> In this case you can surely just use the node which
is provided in
>> caps anyway?
> This is true! So that particular usage case is still
addressed by new
> caps, you're right.
Cool one use case resolved then at least ;)
Richard
|
