[jitsi-dev] Request for comments on Lib Jitsi Meet


#1

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.


#2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- --

···

On 14/08/15 16:56, Hristo Terezov wrote:

Don Alexander

It's a tough job, but some mug has to do it...

RooSoft Ltd


#3

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"? 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? or trim the streams to match the latest
options? if not, how are local media streams cleaned up? are all of the
'getUserMediaWithConstraints' type constraints intended to be passed in
here?
-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?
-'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 ???)

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.

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


#4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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.

I think you will be able to pass options about the resolution and aspect
ratio via the options parameter of createMediaStreams method in Conference
object.

···

On Fri, Aug 14, 2015 at 12:51 PM, Don Alexander <debug@roosoft.ltd.uk> wrote:

On 14/08/15 16:56, Hristo Terezov wrote:

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

--
Regards,
Hristo.


#5

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.

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.

-'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.

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.

Cheers,
Yana

···

On 14 Aug 2015, at 3:30 pm, Brian Baldino <brian@highfive.com> wrote:

Nice work!
-brian

On Fri, Aug 14, 2015 at 10:51 AM, Don Alexander <debug@roosoft.ltd.uk <mailto: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 <mailto: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 <mailto: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


#6

Hi Don,

Are there any plans to move that into the API or is this just wishful thinking?

We’re working on that and we hope to have a first version very soon, so no it’s not just wishful thinking :slight_smile:

Yana

···

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 <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Regards,
Hristo.
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

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.

are all of the 'getUserMediaWithConstraints' type constraints intended to
be passed in here?

I think so, Hristo will give you more information on that.

Yes. It will be possible to pass them.

-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.

-'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.

I think we should create another method for "pinParticipant". Currently in
Jitsi Meet we have the functionality to lock participant and we have the
functionality to automatically change/select participants based on the
dominant speaker detection. So we may have "pinParticipant" and
"selectParticipant" methods.

···

On Fri, Aug 14, 2015 at 5:14 PM, Yana Stamcheva <yana@jitsi.org> wrote:

On 14 Aug 2015, at 3:30 pm, Brian Baldino <brian@highfive.com> wrote:

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.

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

--
Regards,
Hristo.


#8

That would be so useful indeed!
Also I'd suggest to keep all the translations with the GUI part (having
ConferenceErrors and ConferenceEvents as Brian suggested can make it
possible).

Regards,
Zalmoxisus

···

On Fri, Aug 14, 2015 at 11:30 PM, Brian Baldino <brian@highfive.com> wrote:

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"? 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? or trim the streams to match the latest
options? if not, how are local media streams cleaned up? are all of the
'getUserMediaWithConstraints' type constraints intended to be passed in
here?
-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?
-'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 ???)

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.

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


#9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

···

On 14/08/15 23:16, Yana Stamcheva wrote:

Hi Don, > > >> >> Are there any plans to move that into the API or is this

just wishful thinking? > > We’re working on that and we hope to have a
first version very soon, so no it’s not just wishful thinking :slight_smile: > > Yana >

Ahh good to know :slight_smile: The boys over at Jupiter Broadcasting will be
excited then.

Cheers,

- --

Don Alexander

It's a tough job, but some mug has to do it...

RooSoft Ltd


#10

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


#11

Looks really good all. I've opened a PR with some feedback here
<https://github.com/jitsi/LibJitsiMeetJS/pull/10> let me know what you
think. The majority of the changes can be summed up as

   - prefer a promise
   <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise>
   based api over callbacks
   - consolidation of event binding, abstracting XMPP internals from core
   API (signal vs presenceCommand)
   - Prefer options hash over "required items as params" constructor for
   forwards/backwards compatibility
      - ie: function(options) with assertions that throw when required
      params aren't passed over function(requiredA, requiredB, optionals)
   - rename createMediaStreams as share

From the discussion we had in "The Call" the only other question I've got

is around Stream.attachStream and Stream.remove. Just curious if those are
simply creating a Video element and setting it's source, or if they're
doing anything more complicated. If not, it might make sense to create them
as some sort of browser compat layer. If they are doing more, specifically
around presentation, maybe they should be seperate from the core API and
part of a companion UI lib.

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

···

On 14/08/15 16:56, Hristo Terezov wrote:
--

Issac Gerges

Senior Developer, HipChat


#12

That would be so useful indeed!
Also I'd suggest to keep all the translations with the GUI part (having
ConferenceErrors and ConferenceEvents as Brian suggested can make it
possible).

Do you mean to include the current UI module from Jitsi Meet in the library?

···

On Fri, Aug 14, 2015 at 4:14 PM, Michael Diordiev <zalmoxisus@gmail.com> wrote:

Regards,
Zalmoxisus

On Fri, Aug 14, 2015 at 11:30 PM, Brian Baldino <brian@highfive.com> > wrote:

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"? 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? or trim the streams to match the latest
options? if not, how are local media streams cleaned up? are all of the
'getUserMediaWithConstraints' type constraints intended to be passed in
here?
-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?
-'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 ???)

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.

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

--
Regards,
Hristo.


#13

That would be so useful indeed!
Also I'd suggest to keep all the translations with the GUI part (having
ConferenceErrors and ConferenceEvents as Brian suggested can make it
possible).

Do you mean to include the current UI module from Jitsi Meet in the
library?

No. The current structure is good. Sorry for the mix-up. As I understand,
the jitsi-meet will be splitted in 2 parts: this one (Lib Jitsi) and the
GUI part. So I suggest to keep everything related to the translations there
to keep this part as flexible as possible. We do not use the translations
at all in jitsi-meet, and have to remove everything related to
i18next-client every time.

···

On Sat, Aug 15, 2015 at 1:45 AM, Hristo Terezov <hristo@jitsi.org> wrote:

On Fri, Aug 14, 2015 at 4:14 PM, Michael Diordiev <zalmoxisus@gmail.com> > wrote:

Regards,
Zalmoxisus

On Fri, Aug 14, 2015 at 11:30 PM, Brian Baldino <brian@highfive.com> >> wrote:

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"? 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? or trim the streams to match the latest
options? if not, how are local media streams cleaned up? are all of the
'getUserMediaWithConstraints' type constraints intended to be passed in
here?
-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?
-'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 ???)

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.

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

--
Regards,
Hristo.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#14

Some more thoughts:

I notice that there isn't a peer connection wrapper defined/exposed. Is
this something the library will expose directly or will it wrap it and
provide methods for setting descriptions, etc.? TraceablePeerConnection is
nice to have, especially if it can hide the work for things like
translating between Plan B and Unified Plan SDP. I also went through and
tried to document all the ways we're currently using the jitsi meet js code:

1) Accessing RTC.localStreams and RTC.remoteStreams: we let the jitsi meet
code own the stream objects, sounds like that will continue to be the plan
2) RTC.obtainDesktopStream: desktopsharing.js only exposed the
toggleScreenshareStream which assumes only a single local video stream will
be active at one time, so we had to expose one of the lower-level methods
so we could just get the desktop stream. Since desktopsharing takes care
of so many things around the extension/screenshare method, we definitely
wanted to continue to take advantage of it. Sounds like the plan for the
lib is to provide a method that will allow just acquiring the desktop
stream without any other assumptions.
3) RTC.setVideoMute: I think this is already covered in the new lib code
4) RTC.attachMediaStream: Although we don't want the library attaching the
stream on its own, the helper method is nice since it can hide any browser
differences.
5) Adding/removing event listeners
6) RTC.start: we use this, but wish it didn't both automatically grab user
media in addition to initializing. Would be better if initialization logic
was independent.
7) Datachannels wrapper. I don't see this in the lib...what's the plan
here?
8) SDP helper functions. Very useful, though perhaps better suited to a
repo of their own?
9) RTC.createRemoteStream

We've also had to add some cleanup logic...I think jitsi-meet presumes
there will always be a page refresh between calls so there seem to be some
things that aren't happy if a call is restarted without refreshing, so some
cleanup/reset logic would be nice to clear up any state. A "getId()"
function for both local and remote streams that hid any browser differences
would also be nice.

I also notice that the lib now models a "track" as opposed to a
"stream"--is this in anticipation of the goal for webrtc to become 'track'
focused?

All in all libjitsimeet still feels a bit sparse compared to all the logic
that's in jitsi-meet currently.

-brian

···

On Tue, Aug 18, 2015 at 12:29 PM, Issac Gerges <igerges@atlassian.com> wrote:

Looks really good all. I've opened a PR with some feedback here
<https://github.com/jitsi/LibJitsiMeetJS/pull/10> let me know what you
think. The majority of the changes can be summed up as

   - prefer a promise
   <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise>
   based api over callbacks
   - consolidation of event binding, abstracting XMPP internals from core
   API (signal vs presenceCommand)
   - Prefer options hash over "required items as params" constructor for
   forwards/backwards compatibility
      - ie: function(options) with assertions that throw when required
      params aren't passed over function(requiredA, requiredB, optionals)
   - rename createMediaStreams as share

From the discussion we had in "The Call" the only other question I've got
is around Stream.attachStream and Stream.remove. Just curious if those
are simply creating a Video element and setting it's source, or if they're
doing anything more complicated. If not, it might make sense to create them
as some sort of browser compat layer. If they are doing more, specifically
around presentation, maybe they should be seperate from the core API and
part of a companion UI lib.

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
--

Issac Gerges

Senior Developer, HipChat

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

Hey Brian,

Partial answers below.

Some more thoughts:

I notice that there isn't a peer connection wrapper defined/exposed. Is
this something the library will expose directly or will it wrap it and
provide methods for setting descriptions, etc.? TraceablePeerConnection
is nice to have, especially if it can hide the work for things like
translating between Plan B and Unified Plan SDP.

The idea is to hide the SDP handling. The library should eventually run on top of ORTC as well.

I also went through
and tried to document all the ways we're currently using the jitsi meet
js code:

1) Accessing RTC.localStreams and RTC.remoteStreams: we let the jitsi
meet code own the stream objects, sounds like that will continue to be
the plan
2) RTC.obtainDesktopStream: desktopsharing.js only exposed the
toggleScreenshareStream which assumes only a single local video stream
will be active at one time, so we had to expose one of the lower-level
methods so we could just get the desktop stream. Since desktopsharing
takes care of so many things around the extension/screenshare method, we
definitely wanted to continue to take advantage of it. Sounds like the
plan for the lib is to provide a method that will allow just acquiring
the desktop stream without any other assumptions.
3) RTC.setVideoMute: I think this is already covered in the new lib code
4) RTC.attachMediaStream: Although we don't want the library attaching
the stream on its own, the helper method is nice since it can hide any
browser differences.
5) Adding/removing event listeners
6) RTC.start: we use this, but wish it didn't both automatically grab
user media in addition to initializing. Would be better if
initialization logic was independent.
7) Datachannels wrapper. I don't see this in the lib...what's the plan
here?
8) SDP helper functions. Very useful, though perhaps better suited to a
repo of their own?
9) RTC.createRemoteStream

We've also had to add some cleanup logic...I think jitsi-meet presumes
there will always be a page refresh between calls so there seem to be
some things that aren't happy if a call is restarted without refreshing,
so some cleanup/reset logic would be nice to clear up any state.

I think these are bugs and the aim is for jitsi-meet to allow restarting the conference without a page refresh (e.g. when you are left alone in the room, and then someone joins again).

A
"getId()" function for both local and remote streams that hid any
browser differences would also be nice.

+1

I also notice that the lib now models a "track" as opposed to a
"stream"--is this in anticipation of the goal for webrtc to become
'track' focused?

What we currently call a MediaStream (MediaStream.js) already corresponds to a WebRTC MediaStreamTrack -- it has a type (audio or video), and with the current usage it contains a single MediaStreamTrack, although it wraps a WebRTC MediaStream.

So the main aim is to avoid the confusion of having a "Stream" abstraction that does not correspond to the WebRTC "Stream" abstraction.

Regards,
Boris

···

On 24/08/15 12:41, Brian Baldino wrote: