Guidelines and ideas for Vidyo plugin development

[dmartinc]

-Make a copy of the EVO plugin. Following its folder structure is probably a good choice.

-Do some tests on how to programatically call web services (SOAP, WSDL) from Python. For this I made some research and it seems SUDS is the best choice. This link: ​http://stackoverflow.com/questions/206154/whats-the-best-soap-client-library-for-python-and-where-is-the-documentation-fo has a good discussion about it.

-Same way as for EVO, try to build a wrapper for calling the services. Use the same classes for doing network calls with a timeout as EVO uses. See also the CERNMCU plugin for doing calls with timeout.

---

-There is a big difference between EVO/CERNMCU and Vidyo:

*In EVO, a booking is a reservation of a virtual meeting room from a given start date to a given end date. Virtual rooms have a unique Id. Similar for the CERNMCU: we book resources in the MCU from a given start date to a given end date, by booking a "conference" in the MCU, whose id is its name.

*However in Vidyo rooms are permanent. Each Vidyo user has a private room; then he can invite other people (one or more) to his private room to have a videoconference with them. Or, a user with creator privileges can create a new public room that anyone can join (optionally with a password). It is possible to generate a URL for these rooms that people can use to join. These rooms can also be searched by name from the Vidyo client. The id of these rooms is its name (although internally they do have a numeric ID, this is not accessible through the API).

---

-So, the way that bookings are created through Indico must be well thought. Here are some of the alternatives:

1. Indico is a user of Vidyo with creator privileges. When an indico event manager creates an Indico booking, indico creates a permanent room in Vidyo and asks Vidyo to generate a URL to join it, that is then displayed to the manager and in the display pages so that people can join by just clicking on it (similar to EVO). To avoid name collisions, the name of the Vidyo room will be the title of the booking + the indico id of the event. 2 Vidyo bookings in the same Indico event should not have the same name (makes sense).

Example: there is an Indico event "AVC section meeting" with indico id 123. Its manager creates a Vidyo booking. By default the plugin will put "AVC section meeting" in the title, the event description in the booking description, etc. There are no start date / end date fields. There is an optional PIN (password) field (like EVO and CERNMCU). The manager presses "Save". Indico creates a meeting in the Vidyo system called: "AVC section meeting (indico-123)".

Problem of this approach: since Vidyo rooms are permanent, their number will only grow. So there should be a task that checks all the events with Vidyo meetings and erases them after the event end date has passed (leaving a 1day margin). This task could be called daily. If we don't want Vidyo rooms to be created inmediately when the event manager books them, a similar task could create them the previous day (also with a generous time margin). Having these tasks be efficient requieres a good use of the indexing mechanism or store information into the Vidyo plugin's globalData object (see CERNMCU plugin for example of globalData usage).

Or even better (but harder): with a reliable task manager, we could queue mini-tasks that delete the Vidyo meeting just when the Indico meeting ends (or 5-10-30 minutes later, this could be configured). We could also use a similar task to create the room just before the Indico event starts. However, we should also offer the event managers an option to extend the Vidyo meeting beyond the Indico time bounds. In this case, having start / end date fields would make sense. However, this whole create-just-in-time and destroy-just-in-time thing needs to be well thought and take into consideration that users can change event dates after the Vidyo bookings are created.

2. (I like this approach less) When an event manager creates a Vidyo booking, Indico will use the event creators private room for this. Or maybe, give the option to use one of the event manager's private rooms. This way, rooms are reusable; but what happens if an event creator makes several Indico events in the same time frame with Vidyo bookings?

3. Keep a pool of public rooms and have Indico assign them to events when the event managers need them. Problem: somehow we need to track when each room will be used or not, so that we never assign the same room to two bookings at the same time. Also if the event managers wants to use a password for the room, the password for a room will be needed to be changed dinamically when the meeting time comes.

[pferreir]

c181263bdd9e1257f0a6e87d3b9848e3664acba8 and subsequent implement this.