Thanks Yana! Responses inline.
Hi Brian,
Thanks for the feedback!!!
Very cool jitsi team...this is exciting. Some *very* quick feedback from
a first glance, will continue to look more closely.
Conference.js
-'createMediaStreams': this apparently refers to creating local streams,
but the name makes it a bit confusing. should it be
"createLocalMediaStreams”?
Agree. We may call it createLocalStreams.
also, what would the behavior be? if it's called once with audio and
video and then later with only desktop, would it only create the new
stream?
Yes.
or trim the streams to match the latest options? if not, how are local
media streams cleaned up?
There is a stop method in the stream.
Does this mean that the library will not maintain its own data structures
of local and remote streams and that would be left up to the application?
are all of the 'getUserMediaWithConstraints' type constraints intended to
be passed in here?
I think so, Hristo will give you more information on that.
-presenceCommand/sendTextMessage: what are these wrappers for? is the
transport going to be encapsulated inside the lib? would these
transmit/receive over data channel or over signaling or would the channel
be provided by the application? if one corresponds to signaling and
another media, maybe they should be named according to that?
Those are going to use the XMPP connection actually and will send chat
text message in the chat room and presence commands allowing to send
additional information through the presence packets.
I see. Could the the library also include a datachannel abstraction for
sending arbitrary messages and have apis that distinguish transmitting data
over the media path (data channel) and signaling path (xmpp) ?
-'selectParticipant': why 'select' but no pin? can the api document
exactly what the result of 'elects the participants to be the selected
participant or the speaker' will actually do? (i.e. select the HD stream if
in simulcast, else ???)
Yes that’s exactly related to simulcast. We can call the method
differently, maybe: pinParticipant.
Since jitsi supports both 'pin' (lock a participant) and 'select' (request
the HD stream of a participant) I just wanted to check if the library would
support both of those features, I think Hristo explained in his email that
it would.
ConferenceErrors, ConferenceEveents
-could we perhaps get some hooks to allow applications to easily extend
with their own events while keeping upstream merges clean?
e.g. libjitsimeet could also import ExtendedConferenceEvenets,
ExtendedConferenceErrors which would always be empty in the libjitsimeet
repo, but an application could use to add their own specific events and
errors.
Sounds good. However I’m not sure what exactly you have in mind with the
ExtendedXXX events. If we add some hooks giving access to objects on which
we could trigger events, then the implementation can create its own events.
Maybe I’m just not getting the idea correctly.
I have something in mind here but I realize we haven't seen yet how the
library will rely on the events and errors defined in those files, so I
think before going deeper into things I'll wait and see what the usage of
the events/errors looks like.
···
On Fri, Aug 14, 2015 at 3:14 PM, Yana Stamcheva <yana@jitsi.org> wrote:
On 14 Aug 2015, at 3:30 pm, Brian Baldino <brian@highfive.com> wrote:
Cheers,
Yana
Nice work!
-brian
On Fri, Aug 14, 2015 at 10:51 AM, Don Alexander <debug@roosoft.ltd.uk> > wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 14/08/15 16:56, Hristo Terezov wrote:
> Hello, > > As many of you have indicated they wished to be able to use
the lower layers of Jitsi Meet (media streams, sending/receiving xmpp
messages, etc.) without the GUI and layout (and HTML, DOM, CSS, etc.), we
are thinking of splitting the application in two parts. > > All the lowers
layers that others can use will be available under a separate library that
we currently refer to as Lib Jitsi Meet. This is the part that people would
be able to use and on top of which they will be able to build their own
GUI. > > We have tried to summarize the shape of the new API here: > >
https://github.com/jitsi/LibJitsiMeetJS > > Please have a look at this
and let us know if you think this will work for your use case. > > We are
happy to take feed back in this thread or in the GitHub repo itself. > > We
are having TheCall next Monday (early evening EU/late morning US) and we
also hope to hear your thoughts there, although meaningful discussions will
likely have to happen on the list for time constraints. > > Regards, >
Hristo. > > > _______________________________________________ > dev mailing
list > dev@jitsi.org > Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
Well if the API can include options for specifying to codec resolution
bandwidth and aspect ratio of video streams that would be a huge
improvement for people who want to use it for broadcasting collaborative
talks. Are there any plans to move that into the API or is this just
wishful thinking?
Thanks.
- --
Don Alexander
It's a tough job, but some mug has to do it...
RooSoft Ltd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlXOKpMACgkQuipFNInZ6evVDACfboAFyC8sVguKKIJxJy7GS1EH
CN4AnjQ9143Pr2D3afhX3yrb1m5i5my6
=ueG3
-----END PGP SIGNATURE-----
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
