Some of you may know that a new version of the XiVO client is being worked on at the moment. The new look and feel require some work behind the scenes to merge all kind of contacts a XiVO user might have into a single source of information.
What does all this mean ? A personal contact, an entry from an LDAP server or another XiVO user should all be available to the user as one single list of contacts, even if some operations are not available on all kinds of entries.
We already had a directory xlet that merged XiVO users and remote directory entries into a single list. This xlet is used by the switchboard profile. The directory xlet does most of the heavy lifting of merging the different contact lists on the client side. This solution is not ideal for the future of XiVO as we would like to be able to develop a mobile or web-based version of the client without the burden of rewriting the same logic.
The first step of our work on this new client is to move this directory logic back on the server side. To do so, we are creating a new directory service, named xivo-dird, that will be responsible of handling all queries made to all configured directory sources on a XiVO.
This new service will offer a public REST interface. This means that custom client-side applications will be able to integrate the services provided by xivo-dird easily. We are also making this new service runnable without a complete XiVO ecosystem. It will be possible to install xivo-dird on a dedicated server or in a container. The nature of the work done on xivo-dird will also make it easy to run the service in a distributed manner. With some configuration, an administrator will be able to have many xivo-dird servers running behind a load balancer so that it may be used by many XiVOs simultaneously. For example: Avencall has one xivo per office but could use the same xivo-dird proxy for all offices.
We are also designing xivo-dird for extensibility and we are trying to make plugins as easy as possible to create, making it easier for the community to contribute.
Currently planned extension points include:
Backends are plugins that are used to query directory sources. This is where we find the logic for retrieving data from a specific kind of technology. Backends include, but are not limited to, ldap, csv, xivo-directory (the internal directory of a XiVO), xivo-personal-directory (user's personal contact).
HTTP views are different URLs that are exposed by the xivo-dird server. At the moment we know that we will have a json view that will be used by other XiVO services to retrieve lookup results. Other views will be added to support other needs. Phones are a good example of consumers that require a customized view. Adding support for a new brand of phone to xivo-dird will be a matter of adding the HTTP view plugin that formats the lookup results in a way that the phone understands.
The core of the application is responsible for loading all of the plugins. We will probably use a third party library for this job. We have a proof of concept using stevedore at the moment. Concurrency is also managed by the core.
This kind of architecture will become the reference for other XiVO services. Having modular services that can be executed independently from each other will allow us scale the required parts of XiVO when needed.
You can look at the github repository to view the source code and follow our work. Note that the master branch does not include this work yet. The code in other branches are proof of concepts used to confirm that our architecture could handle the kind of load we were aiming for and that our modular architecture could be achieved but this code is not meant for production and will be replaced once we write the production version.