Including dev-media and dev-webapi into this discussion. We need to
determine what to do here from an API perspective.
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
