 So, hello everyone. My name is Alex. I'm from professional services at OnlyOffice. And today I would like to share with you our experience in building connectors. Connectors that allow to edit and collaborate on the documents within any content management applications. So, first briefly, I will try to explain to you what is OnlyOffice and what we do. OnlyOffice is a powerful solution for editing your documents, your spreadsheets and your presentations. Office OpenXML has been chosen as a core format to ensure compatibility with almost 90% of all existing documents in the world. And to avoid any issues by converting the files. OnlyOffice can be deployed on any platform. So, we have a single engine for web, for desktop and for mobile applications. So, and that guarantees similar switch from offline to online and vice versa. We selected JavaScript as one of the most universal languages. So, we use Node.js on the server side. And what's very important, OnlyOffice is already integrated in more than 20 well-known platforms. And in more than 100 web services worldwide. OnlyOffice is available as different packages. So, as Docker container, Snap, Univention server, Cloudron, Amazon image and many others. And of course, our source code is available on GitHub. Now, why OnlyOffice? Our first task is to create very, very powerful engine for processing the documents. And here you can see the list of the points which are very important for our team. OnlyOffice provides comprehensive tool set organized in a tapped interface. So, here you are able to use different features like standard features, table of contents, content controls, bookmarks and many, many other features. And what's very important, JavaScript allows you to enhance additional features to the editors using our API and our plugins. OnlyOffice plugins are applications that allow to add some functionality to OnlyOffice editors. We divide all plugins into visual that just add some buttons, maybe some menus to the interface. Then non-visual plugins that open some dialogue, some context menu. We do have system plugins that just works in the background. We have non-system plugins that can be started by clicking on the button. And of course, we have all the objects that allow you to insert some information into the document itself. We already have few plugins and our users are using these plugins to translate texts, to use services like citation generations, to use web charts like telegram in the document editors interface, to use reference services like Mandalay and Zotero. And many, many other features are supported when you use our API. So right now, different developers worldwide are experimenting with our API using our plugins. OnlyOffice editors are based on HTML5 canvas and that has lots of advantages. So HTML5 canvas uses its own internal tools for rendering the documents. So every single element can be rendered down to the last pixel. And that allows to use OnlyOffice in any browser on any device. That's very important. And what's also very important, and that's one of our key points, our client-side performance. Talking about client-side performance, we talk about advanced sharing permissions. There are few standard sharing permissions like view or edit. But we also do support additional like commenting, like filling forms, like track changes, like modifying filter. And of course, of course, restricting, downloading and printing is also available. But you may say, OK, we're able to use that feature in any web editor. But when we talk about advanced permissions, we also talk about core editing. So for example, here you can see a document and three different persons. These three persons are working on the same document. The first is editing that table. The second one is using track changes mode. And the third one just adding some commands to the document. But what is the most important thing? Nobody is disturbed here. And that's only possible when we move the processing to the client-side. One more example. A simple action like undo your last move can be a very hard job if you work in co-editing mode. So OnlyOffice allows you to use undo feature without affecting your co-authors. OnlyOffice has its own lists of the actions mapped to every user in the document. So you are able to use your undo without affecting any other users. So, and now about security. That's a crucial question for everyone who works on the documents online. What we did on the server-side? We used JSON WebToken. So we are able to sign all requests between storage, document server and your client. We also have additional features for configuring the cache of the server. And we also guarantee that no user data is stored on the server. We also do support additional security features like watermarking, like secure form filling. That's when, for example, you have access to some area in the document and nobody else has that access. So we also have end-to-end encryption in our desktop editors when working with our OnlyOffice portals. Now a little bit about performance. If you need, let's say, 1,000 simultaneous connections, you only need a single server with 8 cores and 32 gigs of memory, just because you need your server only when opening a document and when closing it. That's all. Between these two points you don't need your server anymore. And more. If you need more power, so you are able to run OnlyOffice cluster with all dependencies in a distributed manner. We have our open API that allows you to add some additional features or to integrate our editors into almost any document management system. For example, the first one, document builder. Document builder is a core of document editors. You are able to create documents using JavaScript. You are able to convert your documents to any other formats, let's say PDF. So you are able to create your documents from your database using some templates. And my favorite portion, you are able to add different features to OnlyOffice editors basing on your use cases, on your experience. For example, if you need to mention some user in your document editor, so you are able to do the following. Document editors will connect to your database, will request a list with all users in your database. So then you are able to select every single user. Then our editors will inform your system and you will notify a user that he was mentioned. So that's all you need to do. Next one, content controls. That's one of the most important plugins. I think three out of ten developers use that plugin. I will try to make a small example how it works. So let's say you work on a document. The document is stored somewhere in your cloud, maybe on your server, in your storage, but the document has an area. That area called content control takes the data from another storage, from your private database or some other storage. And what's the most important thing, you may not even have access to remove or to edit that content control. And even more, you are able to share the document with anyone who won't be able to see the content of that area. So that's one of the most simplest features. Once again, there are lots of features available when using our API version history. Just left panel with all actions, all actions, and here we don't talk about track changes. No, just usual editing. You just need to save some metadata to your storage when you save a new document. And when opening that document, you take that metadata file and open it. That's all you need to do to display that version history panel. One more thing. Using drag and drop, you are able to work with different iframes within a single HTML page. And you are able to use drag and drop to move some information from your, for example, chat to the document editor's interface. For example, when you work with Firefox, that's okay, but Chrome doesn't allow to move such information. So what we did, we just created a small plugin called ExternalListener that allows you to catch the information dragged from your chat. So our online editors have beautiful API that allow you to integrate into almost any, any document management systems. We already created few connectors for NextCloud, OnCloud SharePoint, Alfresca and Confluence. New connectors for HumHub LiveRay just created. But the most important thing, there are lots of developers who created their own connectors. Guys from xweeklycfile.pdo exo platform, they created their own connectors for only office desktop editors. Now, briefly explain how it looks like using connector with NextCloud. You need to create some kind of global settings and user settings when creating a connector to only office. So you may create server settings using configuration of your server, but we did admin menu for NextCloud. And here you just see a few fields. The first one is document editing service address, just address of the only office document server. One thing, the server should be accessible from NextCloud storage and from your client. And of course, NextCloud storage is also available for document server for downloading the files. Then, secret key, very important field. You are able to sign all requests, as I said, so using that secret key. Then, if you are going to use only office and NextCloud on a single server, so you need to use advanced server settings. Only if you use NextCloud and only office on a single server. What about user settings? We have few additional options. You can configure some user parameters like restricting access to editors to certain groups in NextCloud. Then, you can set up default files, default formats that will be opened with only office editors. You also are able to customize your interface, for example, to compact toolbar. And you also are able here to enable watermarking if that's necessary. Of course, you need to create some context menus. So, we did it for NextCloud. Here you can see two additional buttons were created for NextCloud. We already did some features for NextCloud and we have plans to add additional features. For example, we already created very interesting integration point. Integration with right menu of NextCloud. Here you are able to use NextCloud sharing dialogues. Maybe to integrate our editors with NextCloud applications like video chat or maybe for NextCloud talk, something else. And we have many, many other plans how to add different additional features to integration. We have our roadmap and in that roadmap there are the tasks like creating new industry-specific connectors. But as well, we are trying to add additional features like using VOPI protocol, like locking the file while editing. That's very important when using NextCloud integration. So, that's one of the many, many features that we are going to do. So, and of course, if you have any questions, if you would like to contribute, if you would like to send some pull requests, some issues, you are welcome. Thanks a lot for your attention. I have a question. How many developers do you have on the editors? The question was how many developers we have. So, right now we have about 20, maybe 25 guys who are working on the editors. The question was if ODF formats are supported. Yes, of course, we do support Office Open XML as well as ODF format. So, ODT files are supported. We do support almost all document formats that we have. So, the question is when we work with our editors, we need to convert these files to Office Open XML standard, then edit it. And then, if necessary, to save it back converting to ODT, for example. So, the question was when we are going to release a new version with pure tables. Yeah, we are going to release it very soon. Yeah, just I guess a question of few weeks. We have few release candidates with that feature and our quality assurance team is working on it. Because we saw sort of viewing interface in the current editors. Yes, you are absolutely right. Right now we do support viewing, yeah, but we do not support editing. As I said, just question of few weeks. We are going to release it. And another question, I saw that you had a document. The question was when we are going to support external links for elements like charts and like tables, yeah, for all the objects. So, that's a very good question. We are working on that question right now. Right now we plan to find some work around and that's very hard to realize because, yeah, because we do support our own OLA objects. Yeah, but we plan to do that. We know that that's very interesting and that's very required feature. Yeah, the question was how we deal with user interface changes when working with different modes like mobile, web and desktop. As I said, we have a single engine and we have talking about desktop editors. We have Chromium framework that allows us to work with desktop as if you work with web browser. So, almost the same for mobile versions. So, but here we need to adopt, of course, mobile versions for compact displaying the menus. But we don't see any critical troubles here, so we do it. You may try. Any more questions? Thank you.