Hi developers, Let me first say that, IMHO, this usage of redis is an outstanding architectural decision. I'm integrating bbb into a RoR app. Logging bbb events in the database was very simple, just by subscribing to the redis publication. Looking forward to 0.81, where all events will go through redis!
Now to the point: 1. Why is the externalUserId not sent in all redis' messages? 2. Was this a design decision?
Having the externalUserId in every request will be very useful to avoid having to figure out the mapping between external and internal user id after the first message.
*User joined message* message: {"externalUserId":"3","internalUserId":"45","meetingId":"287da0651bbe7af557 b588ce0c9aeaa9a39487a6-1353098991675","role":"VIEWER","messageId":"UserJoin edEvent","fullname":"user1"}
*User left message* message: {"internalUserId":"45","meetingId":"287da0651bbe7af557b588ce0c9aeaa9a39487a 6-1353098991675","messageId":"UserLeftEvent"}
On Fri, Nov 16, 2012 at 4:13 PM, Federico <federicobo...@gmail.com> wrote:
> Hi developers,
> Let me first say that, IMHO, this usage of redis is an outstanding
> architectural decision.
> I'm integrating bbb into a RoR app. Logging bbb events in the database was
> very simple, just by subscribing to the redis publication.
> Looking forward to 0.81, where all events will go through redis!
That's the plan. The idea is that the Red5 app and NodeJS app (for HTML5)
can sync with each other by subscribing to redis pubsub.
There's still more work to be done. If anybody can help, then the work gets
done sooner.
> Now to the point:
> 1. Why is the externalUserId not sent in all redis' messages?
Our first playback format was very simple. What we wanted was to just be
able to play the slides with audio. There was no need for externalUserID so
we did not include it.
> 2. Was this a design decision?
> Having the externalUserId in every request will be very useful to avoid
> having to figure out the mapping between external and internal user id
> after the first message.
Agreed. Can you please create an issue? We'll include it as part of the
refactoring above.
> *User joined message*
> message:
> {"externalUserId":"3","internalUserId":"45","meetingId":"287da0651bbe7af557 b588ce0c9aeaa9a39487a6-1353098991675","role":"VIEWER","messageId":"UserJoin edEvent","fullname":"user1"}
> *User left message*
> message:
> {"internalUserId":"45","meetingId":"287da0651bbe7af557b588ce0c9aeaa9a39487a 6-1353098991675","messageId":"UserLeftEvent"}
> Thanks,
> Federico
> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/bigbluebutton-dev/-/xM4Y3LofPgsJ.
> To post to this group, send email to bigbluebutton-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> bigbluebutton-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/bigbluebutton-dev?hl=en.
On Sat, Nov 17, 2012 at 9:14 AM, Richard Alam <ritza...@gmail.com> wrote:
> Hi Federico,
> On Fri, Nov 16, 2012 at 4:13 PM, Federico <federicobo...@gmail.com> wrote:
>> Hi developers,
>> Let me first say that, IMHO, this usage of redis is an outstanding
>> architectural decision.
>> I'm integrating bbb into a RoR app. Logging bbb events in the database
>> was very simple, just by subscribing to the redis publication.
>> Looking forward to 0.81, where all events will go through redis!
> That's the plan. The idea is that the Red5 app and NodeJS app (for HTML5)
> can sync with each other by subscribing to redis pubsub.
>> Now to the point:
>> 1. Why is the externalUserId not sent in all redis' messages?
> Our first playback format was very simple. What we wanted was to just be
> able to play the slides with audio. There was no need for externalUserID so
> we did not include it.
>> 2. Was this a design decision?
>> Having the externalUserId in every request will be very useful to avoid
>> having to figure out the mapping between external and internal user id
>> after the first message.
> Agreed. Can you please create an issue? We'll include it as part of the
> refactoring above.
>> *User joined message*
>> message:
>> {"externalUserId":"3","internalUserId":"45","meetingId":"287da0651bbe7af557 b588ce0c9aeaa9a39487a6-1353098991675","role":"VIEWER","messageId":"UserJoin edEvent","fullname":"user1"}
>> *User left message*
>> message:
>> {"internalUserId":"45","meetingId":"287da0651bbe7af557b588ce0c9aeaa9a39487a 6-1353098991675","messageId":"UserLeftEvent"}
>> Thanks,
>> Federico
>> --
>> You received this message because you are subscribed to the Google Groups
>> "BigBlueButton-dev" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/bigbluebutton-dev/-/xM4Y3LofPgsJ.
>> To post to this group, send email to bigbluebutton-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> bigbluebutton-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/bigbluebutton-dev?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-dev" group.
> To post to this group, send email to bigbluebutton-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> bigbluebutton-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/bigbluebutton-dev?hl=en.
