[Members] XSF roadmap
jehan at zemarmot.net
jehan at zemarmot.net
Wed Nov 10 23:33:27 CST 2010
On Wed, 10 Nov 2010 22:38:08 +0000, Matthew Wild <mwild1 at gmail.com>
> On 10 November 2010 22:31, Justin Karneges <justin at affinix.com> wrote:
>> Implementing audio/video is hard, and it is still an ongoing effort. I believe
>> it is still possible, though rare, to have weird issues with GStreamer-based
>> apps (essentially all of the open source IM clients) such as failed audio or
>> one-way audio. Traditionally, multimedia has not been a strong point of open
>> source, but GStreamer represents one of our best efforts, and I do not think we
>> are far away from a world where audio/video multimedia operates perfectly in
>> free software. Please note I am not talking about networking here, but just
>> basic hardware and multimedia engine operation and the end of issues like "my
>> microphone doesn't work in Windows". In general, I think most Jingle failures
>> today are about NAT, codec mismatches, and incomplete protocol (Jingle, ICE).
> I largely agree. What would be most interesting would be a client that
> (perhaps only in beta versions, or perhaps not) allows a user to
> report when a Jingle call was unsuccessful for them. This would send
> anonymised logs of the negotiation to the developers (and figure out
> client versions where possible), and then it can then be decided
> exactly what the real-life issues are...
Yes this would be awesome. Basically we could make a public proposition
to all client developpers (by creating a blog entry and also
individually pinging those we know) to push this "non-feature". But it
should be simple to implement.
Technically there could be an automatized blog behind a JID, so that
this feature would basically simply send a XMPP message (after all,
people who try Jingle are already connected via XMPP! Let's use this to
send our logs). This should be fairly simple to implement for every
implementer: in the window of each Jingle attempt, a simple button:
"report a audio/video call failure". The user clicks, has eventually the
possibility to give failure details ("my recipient could see me, but I
didn't see him", etc.), then it sends a message with a maximum
information about the user configuration, its client's version. For even
more information, it could send a message to the other client to request
the same information from it (if the recipient supports this feature),
along with a bug id, so that the other client can refer to the same.
An example of such message (no namespace added, so this is wrong, just
for an idea of the thing) sent to the XMPP bot:
<message from='romeo at example.net' to='xmpp-bot at xmpp.org' id='hjh'
<software name="Pidgin" version="2.7.0">
<library name="libpurple" version="2.7.0">
[... various other information software specific, about its
installation, its configuration ...]
<system kernel-name="linux" kernel-version="2.6.30-05"
[... various information system-related and useful depending on the
current bug report ...]
[... there could be other informations, whatever the client is able
to detect which could be useful for the current issue, about the
network, etc. ...]
<software name="Psi+" version="0.15.3179 Beta (Nov 9 2010)" />
[... any information collected automatically from the recipient,
like the client's version and its system ...]
<system name="Windows" .../>
<user-description>I could not see my love, though she could see
[... internal errors as detected by the software itself, if any ...]
And this message could be sent to the recipient to request additional
information (more details about its client configuration, system, etc.),
as well as the "bug tracker" to send it to, and an id reference.
<message from='romeo at example.net' to='juliet at example.com' id='hjh'
<bug id="1234" sent-to="xmpp-bot at xmpp.org">
<other-party-description>I could not see my love, though she could
Then the bot receives the information, keeps this in some db for
reference of issues about a project (here: improving audio/video
Jingle!) of the XSF (and also we could make statistics and see how is
going the network, is it improving? Less bugs?), and forwards the
information to the relevant entities (here: Psi and Pidgin developers).
Something like that could be awesome. That could be used for other of
our projects also (like for Jingle File Transfer: if it fails, a similar
message can be sent, etc.).
> We need more data :)
We do indeed!
P.S.: actually rather than a message, an iq would be better, so that
the bug id would be received from the bot/bug-tracker as a response
(because if the initial client sets it, it may conflict with another
one, but when I thought about this, I was lazy and didn't not want to
change my example :p).
More information about the Members