On 8/15/2012 6:57 PM, Jason Smith wrote:
Including dev-media and dev-webapi into this discussion. We need to
determine what to do here from an API perspective.
Per our discussion earlier today, this falls into the Media Capture Task
Force, which we've been taking part in (and Anant is an editor for).
Our agreement earlier today was to bump the conversation there to try to
get consensus on an API for image capture and see if any changes are
needed, and if it covers all the use cases reasonably. We went forward
with the implementation in order to see how it works in practice to
guide standardization. We fully expect changes or even a redesign being
possible, but the best place to discuss it and propose changes is there.
This is a decision that's bigger than just Mozilla. This was discussed
before; the agreement (including Brendan) was to go forward with this
proposal. Discussion is great, but whatever comes of it should go to
the Media Capture list, or better yet occur there to begin with.
The mailing list is [email protected]. The next telco has a
doodle that closes today for when it is, perhaps Aug 23rd.
Sincerely,
Jason Smith
Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.org/
On 8/14/2012 10:54 AM, Jonas Sicking wrote:
On Tue, Aug 14, 2012 at 10:24 AM, Jason Smith <[email protected]> wrote:
Hi Jonas,
In doing testing of mozGetUserMedia, I've generally felt a sense of
awkwardness a bit towards the API design to combine generation of static
content (pictures) vs. dynamic content (audio/video) under the same
exact JS
function. Why was that design decision made? Could this design decision
survive standardization to unprefix eventually? Why not separate the
static
content logic vs. dynamic content logic into two separate distinct
functions? Why have the function return two distinct incompatible object
types in the first place? Have other vendors (e.g. webkit) seen our
altered
approach for this API design? What was their thoughts on it?
It almost feels like this below:
mozGetUserMedia(...) {
if (picture) {
Do this bunch of functionality for static content and
return a File
Blob
}
else if (video, audio, or video and audio) {
Do this different set of functionality for dynamic content and
return a MediaStream
}
}
They feel like entirely distinct pieces of functionality with entirely
different objects returned that are incompatible with one another.
From a
general feeling of writing test cases and sample content, it almost
felt the
logic for static content vs. dynamic content should be entirely
different
function calls, as I'm calling each one for entirely different purposes.
Would be interesting though here to get feedback on this from web
developers
to see what they think about this as well.
This API has been owned by the WebRTC team and I have expressed the
same concerns as you are mentioning above. The two "modes" are
actually even more different since the "picture mode" will likely use
"intents" to switch to a different app where the user can pick/create
the picture. So the UX is dramatically different which likely is very
important to app developers.
Additionally we have had for a very long time an API for the "picture
mode" by using the <input type=file accept="image/*">.click() API
which works in both Mobile Firefox and Chrome for android.
To make the situation more complex there's also the fact that there
are use-cases for getting a "snapshot video" and "snapshot audio".
I.e. for UX behavior exactly like that of the "picture mode", but
where the user picks or creates a static audio or video file which is
then returned to the page.
I think having separate functions for the "snapshot" UX behavior and
the "streaming" behavior would make a lot of sense.
/ Jonas
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
