L.R.N wrote:
Peter Saint-Andre-2 wrote:
Is that of interest to more than 1% of users?
Users are interested in nothing. They may use the possibility once it is
available, or they may not, but until then they really don't care.
Peter Saint-Andre-2 wrote:
What kind of information do such plugins usually communicate?
Depends on the way they get this information. And since there is no such
standard (like "Inter-Process Now-Playing Information Exchange Protocol" or
something), a fair amount of different schemes exists. Ranging from direct
message sending to complex plugin interconnections and third-party gluing
applications.
That's "how", not "what". I'm interested in learning exactly which data
fields they communicate. For example, do they really communicate
information about (as you say) the "player name (and version), format
(codec/container), bitrate, file size, sample rate, channels etc." If
so, why? When I want to know what tune you're playing, do I really care
about the number of channels ("gosh, you're into quadraphonic too?!
kewl!") or the bitrate? That's geeky stuff that 99% of real people don't
care about.
You could include all that kind of thing as extended information, but I
don't see a good reason to include it in the core data format.
It also depends on messenger processing power: some of them
can handle variable data and format it into a string, others just display it
'as is'. By the way, XEP-0118 does not defines how exacly the information
should be presented to end user.
Correct. Our specifications don't define or limit GUIs. That's the job
of client developers.
Peter Saint-Andre-2 wrote:
You may be right. But first I think we need to do some research to see
what information is really of interest.
What kind of research exactly? Internet-poll? Player's nowplaying capability
test?
Maybe a user poll or at least research into existing "now-playing"
plugins as I discussed above.
Peter
