 So, we are the members of the IIT BombayX team. This year's project theme was storage solutions. So, we had three projects based on them. These are the three projects enhancement of sunbird telemetry to support local storage, implementation of content repository for open edX and sunbird project. All these three projects have many similarities, so we required a change of order of the presentation. So, one by one we will be coming up and presenting to you our respective parts regarding the overall theme of the project. So, at first I would like to call my colleague Jay and we will be talking about the first open stack Swift and Keystone servers. So, these all are the points which we will be covering in our presentation. Good morning everyone. So, first of all I will talk about why exactly we needed to create a local storage storage service. Sunbird and open edX uses some cloud services which are public and to there are some issues of there can be some issues related to security privacy. So, why by implementing the private cloud service we can configure the storage solution as per our requirements, we can set our own security measures, we can even improve the privacy of our data. So, that was the whole motive to create a private cloud at this IIT Bombay campus. So, this is the basic block diagram of Swift architecture. Whenever client requests any for sends a request for any data we have a load balancer that it is one of the servers like a Parture engine X which balances the load and sends the request to the access tier of the Swift architecture which consists of the proxy servers and the ring. Their combination helps in redirecting the request to the particular storage container where we stored where our data is stored. So, the ring structure helps because it has partitions of it maps to which storage container it is stored. After installing the Swift we also needed to create an authentication system to authenticate the user and the coming request. For that we use the OpenStack Identity service which is called as Keystone. We integrated Swift with Keystone and how it works is a user sends username password and the tenant details. Tendent is nothing but the project on which the user is working. It sends this user sends this request to Keystone and Keystone returns an authentication token along with an endpoint URL. At that URL user sends that token and request for the API which he wants to access. So, the APIs which are provided by Swift are of three levels. Account level APIs, container level APIs and object level APIs. Accounts have the details of containers and containers have the details of object. So, what these APIs do is they show create, update, delete, metadata about all these things. Account level APIs list the account details it lists the containers under it. Container level APIs show the objects in it and object level APIs does all these operations on the objects. So now we will be talking about our contributions. So first of all we installed OpenStack Swift and Keystone service on a VM provided to us. We tested its functionality by creating temporary accounts and storing data in it. And once we were sure that it's working full proof, we created three major accounts. One is for OpenEDX, one is for telemetry and the other is for Sunbird content. We also created a user manual for everyone to use to show how to use Keystone and Swift. That manual was used by team members to create the APIs which were to be called by other APIs. It also provided support to all team members regarding Sunbird and Keystone. And at the end we also created documentation about Swift installation. In that we have mentioned the errors, mentioned the problems which we faced and how we solved it and all those things. About the learnings, in the beginning we first learned a lot about the theoretical aspects of the cloud. And while installation we dealt a lot with system level, so we worked a lot on system level so our system knowledge has improved. And we have learned how to operate Swift and while it's installation we have faced so many troubleshooting issues and we have also learned how to document. There were quite a few challenges that we faced while installing these two things. The first one was changes to the configuration file of Swift. There we required many parameters in the various configurations file to be modified according to our need. The second was installation of Keystone. It turned out to be a two to three day process because we got an unexpected package error due to some dependencies. So we had to keep on uninstalling everything and then re-installing it. It took two to three days to get just the installation of Keystone done. And then the third one was using Keystone to access Swift. The token which we require how to generate the process of generating and send the token and then using that token to access Swift was also one of the challenges that we faced. The future scope of this project as we means the Swift is highly scalable. By scalable we mean that according to our requirements if say we want more of a storage then we can just add the storage hardware and we can connect with Swift. If we want to handle a lot of traffic then we can just add another proxy server or add another load balancer and accordingly map it to Swift. So its scalability is a very good thing which we can implement which helps us in implementing it on a large scale. So next up I will be calling other two colleagues to present about the content repository. Good morning everyone. We will be talking about implementation of content repository for Open edX. The objective of our project was to integrate Open edX with OpenStack so that the OpenStack settings could be configured to store its data on OpenStack Swift object storage. Presently Open edX data is stored in a public cloud service but since a private cloud service has advantages like security and privacy and customization provisions so we have decided to create a local content repository to store data related to Open edX. To implement our project we basically followed whatever documentation was there for Open Stack Swift. According to that we made a server-wares file and then we granted the necessary authorizations for the Swift containers. We had to include several settings related to OpenStack and Swift auth version 3 and these parameters were provided to us by Utkar Sanjay who had previously installed OpenStack on the VM. After we made the necessary changes on server-wares file we ran three ansible roles. The first role is OpenStack role and it basically consisted of creating the Keystone Client and Swift Client and also installing the Python packages system requirements and other requirements on the Open edX machine. The second is the edX app role which established communication between Open edX with OpenStack Swift and it did so by creating application users and user directories, log directories and by installing those packages on which LMS and CMS rely and the third was Open edX role with salary changes. Salary is a background process which runs while generation and downloading of grade reports. So after we ran these three roles the Open edX settings was configured and its data could be directly stored to Swift and it could also be retrieved from there. So we have a short demo video to present the same. We have logged in as a staff. Here we will be getting the option to generate grade reports. The newly generated grade report will be added in this list. So this is the new generated grade report which can be retrieved through browser. The grade report was downloaded. We have also checked it through Curl using the URLs of Swift object storage. These are the metadata and these are the contents of the grade reports. So we learned quite a lot while enhancing the content repository for Open edX. Our technical learnings included learning ansible. We learned how the control machine manages various remote nodes and running commands on remote nodes, creating files and doing installation of various packages. We learned about what are ansible tasks, playbooks and what are ansible roles. Then we studied the Open edX architecture thoroughly to be able to make configuration changes in the server files. Similarly, we had to study about OpenStack Swift as well. And finally, since we followed some documentation to make the changes in the files, had that documentation not worked, we would have required to make changes in the code itself. And for that, we studied Python and Django REST framework. For non-technical learnings, we learned how to troubleshoot and problem solve. Like just following the documentation obviously didn't lead to the results in one go. We had to make several changes. There were many, many errors and we had to fix them. And thanks to our mentors and the system admin who helped us in guiding, who helped by guiding us, the future scope of this project involves the implementation of other use cases. Right now, what we are doing is we are just able to generate the grade report and store it on this OpenStack Swift. But we can also extend it to identity verification, execute temporary URLs, which are still being stored on the public cloud. So now I would like to call Pradeep and Tanmay for giving a presentation on installing Sunbird and understanding Sunbird architecture. Hello all, I'm Pradeep, he's Tanmay. We are going to talk about installation of Sunbird and understanding architecture, what kind of problem we faced and what we have learned during this step. We are going to talk about our contribution and learnings. So we are not going in detail about the installation because of the time limit and we have already presented the installation demo to all the intents. So basically, we have installed Sunbird on two machines. On one machine, we are making changes in codes, building codes and building Docker images and pushing it to the local Docker registry. And on another machine, we are pulling the images from the local Docker registry and testing the codes. So it was not very easy to install Sunbird on these machines because as previous teams have already mentioned that they have failed couple of times. We also failed couple of times because the environment was new to us, the technologies were new to us and also on the official documentation they have not properly returned the installation steps. There are some of steps missing in the documentation. So what we did was after installing Sunbird successfully, we presented a small demo to all the intents and we have created one of our own documentation which includes step-by-step guide to install the Sunbird and it also includes some of the most common errors we face and how to solve them. Now, Tanmay will talk about the Sunbird architecture. Now that we have installed Sunbird server in two machines, now our foremost task was to understand the architecture so that we can contribute to it and make some development work. So after studying the code, we have come up with this diagram. This above one is the Sunbird system diagram. So any request which is coming to Sunbird, it will first hit the nginx proxy server then according to the path like slash api or other path slash, it will redirect it to Kong server or to player container. And from Kong, it is also it's a api manager. So according to the path again slash learner or slash content service, it will again redirect those requests to a learner service or container service. Container service is there for managing the courses and contents of Sunbird platform and learner is there to create and manage users and organizations. And in below, these are the helper containers that are running, admin util, eco service container and actor service container. And we have the three databases there, Cassandra, Postgre database and Elasticsearch. And in below, we have the data, the content architecture of this, the storing content architecture of Sunbird. Earlier, they were only storing data in accept storage. And this left portion, we have added IITBX storage. We have provided a Django server in it and a Keystone authentication and the main Swift storage in it. So challenges we faced, first of all, as I already mentioned, the technologies were new to us, environment was new to us. So it was very difficult to install the Sunbird completely successfully. These are two main common errors that we have faced, the connecting the Ansible host. Because of this error, the Ansible was not able to install some of the packages and the connecting to Postgre server with Docker network. The Kong is storing its data to the Postgre. So there was some connection, Kong required connection to this Postgre server. So it was not able to connect. We have mentioned all these errors in the error guide as well. So as we have faced all the challenges, we have also learned many like Ansible, Docker, Key Clock as a technical terms. And in non-technical, we have never lost patience. Like we were stuck at many places like installation. We were stuck for two weeks. But with the help of our mentor and from getting guide from internet, we have solved our problems. So next Chandrani and Shreya will come and talk on the topic adding new events to Sunbird Portal. Hello everyone. I am Chandrani and she is Shreya. And our work was to add new events to the Sunbird Portal. Now the Sunbird Portal already had some events which were being captured and the corresponding data was being stored in the ixtap platform. Now what we did was we created events of our own. And as a sample, we took a bookmark event. And we stored the corresponding data on the local storage. Now for this, we had to go through the data structures and the code flow of the events already present. And then we implemented those steps. And we stored the data corresponding to our event on a local storage. And we proceeded like that. So first of all, we studied the events that were already there. That is start impression like that. And as you can see, we have added two sub-events under the bookmark event. That is the bookmark added and bookmark removed. And we also specified some certain fields for the eData structures corresponding to the events. So the main event was bookmark. And whenever a user clicks on the bookmark, the corresponding data is stored. And this event is triggered when the user bookmarks are contained. And when the user removes the bookmark, the bookmark removed event is triggered. Now we'll be telling in details about the event. Now the eData structure for the bookmark. Each and every telemetry event that is present already in Sunbird has a defined structure where the eData structure part is that part which is specific to a particular event. So since we have added the bookmark added and bookmark removed events, the eData structure for both are same. We have a bookmark ID that is a unique ID generated at the time when the bookmark is clicked. A component type which describes that it is a bookmark added or bookmark removed. A component user ID which is the content ID of the content which is a bookmark. On the Sunbird portal, we have a courses page. And under that courses page, we have a content. So the component uses ID refers to that content ID. And the course ID is the course ID of the course that is being viewed. So the bookmark event flow. To add the new event, we have to first read the code flow to add a new event. So there were already many events present. So we had to go through the code and analyze where have to make the necessary code changes to add a new event in the Sunbird portal. So first we have added a bookmark button on the Sunbird portal. And then in the telemetry service, the functions relating to the event are to be added. So we have made changes in the telemetry service code, the telemetry library code and the telemetry sync manager. Syncs the data that is being generated with the extra platform which are now being directed to the ITBX Swift storage. The extra platform has the data APIs. But we are now storing it on the ITBX platform which will be discussed in the next section. Now this is a sample screenshot of the Sunbird portal. We have added the bookmarks button out of which one is clicked and the other is unclipped. These are the logs generated. This is for the bookmark added and this is for the bookmark removed. We have the bookmark ID generated, the component type, the component usage ID and the course ID. These are the logs for the specific event that are being clicked. The other events regarding the user ID, the timestamp that are already there in the common data structure of the event. Now coming to the learnings, we learned a lot during this project. The entire Sunbird portal was written in AngularJS. So first we had to go through that. We also had to go through Docker because each and every time a change was made in the Sunbird portal, we had to implement that change in the Docker to see the changes. We learned about the telemetry events of the Sunbird platform and we learned a lot how to work in a team because each and every event that was there had to be dependent on the other one because first the installation had to take place. Then we had to go through the course flow. Then the event flow could be followed. And since this was a very complicated project and there was lack of proper documentation, so we learned how to go through complicated projects and through the course. Future scope, right now what we are doing is that we are storing the data relating to the event in the local storage. So further we can analyze the data and reports can be generated. And we have provided a way how to generate an event and capture data relating to it. So similarly any other event can be added like this. Now I would like to call Utkarsh who will be talking about storing telemetry data on our local storage. So as they have discussed earlier, the need for storing our data locally was because Sunbirds presently stores the telemetry data on the AXTEP platform which is not accessible from IIT Bombay. So we cannot analyze the data. So here my contributions were first to observe the places from where we require the data. Because the architecture of Sunbird is a bit complex, so determining the places where the data flow from where we can capture easily, all those things were first observed. Then we stored this, we captured this data and we stored it on a file on a system. And periodically like once a day we send this file to our Swift storage using our custom Django APIs which will be discussed later. So this is the telemetry data flow. Initially the top two events and there are many events which Sunbird has already created. So all these events send their data to the AXTEP via the sync manager. We added this bookmark event but there is no Sunbird API for that. So what we did was that we stored its data on a log file. Parallel what we did was that to get a better view we took data from the sync manager also and we stored it on a log file. So we have basically all the syncing logs are also available. And then we stored it on our Swift storage. So my learnings here were working procedure of any REST API. That was a major learning because understanding how REST works, how requests are sent and responses are received that was a major thing. Then REST APIs were using Node.js so Node.js was also learning. And we had to use Docker quite a lot because as it was discussed we used two VMs. One for building images and one for pulling them. So like making changes on one VM and bringing it to other required use of Docker. For non-technical working in groups as discussed it was a very large group and our work was divided in such a way that each one needed the help of the other. Interaction via work meetings our MAM conducted regular status checks. So it helped us understand where our flaws are and we can proceed in a better direction. And this one thing I learned was that meeting deadlines. How to just keep in mind the deadlines and carry on. So the future scope is also like we can in a similar pattern we can capture the logs of other sunbird features not only telemetry other features also capture their logs. We can keep it in a file and store it to the Swift. And in a later course we can access these reports this file logs because they are now accessible to us as they are on a local server. So we can access them we can analyze them and we can generate reports which will help the provide better courses and new courses to the students. So now I would like to call Aditi who will talk about REST APIs. So I'll be telling about why and where have we used REST services in our project. So talking about REST, REST stands for representational state transfer which means whenever a client requests a server for a resource the server in response give the representation of the resource state to the client. So in our project sunbird uses REST extensively for example the organization API, the user API, the course creation API, telemetry API and also OpenStack Swift provides the REST interface. So we can easily access the storage using REST services. Talking about the benefits we had with REST, REST hides the implementation details from the caller. Like if we have to change our storage from Swift to any other storage that won't be visible to the caller. REST API implementation can store data anywhere without affecting the sunbird portal. Requests are independent so there is a easy distribution of the modules and the clients are server independence. State is controlled by client not the server. So if any time there is the server is down the previous requests are always stored with the client in the application state. So presently the contents are stored on the 8 step remote server. We wanted to implement the storage on our private cloud so we modified the content upload API to store data on our private cloud. This is an instance of uploaded content. We have tried to upload various PDF text files and JPG files to our private storage Swift. And next talking about the learnings, I had to learn Python and Django framework and also go through the architecture of OpenStack Swift storage. I learned how to deploy the REST API services and also tested the APIs using Postman. And we also have implemented few of the practices of agile methodology in our project execution. So next I'll be calling Arushi and Samadrita and they'll be talking about encapsulation of Swift APIs within Django APIs. Hello everyone. So why do we need to encapsulate Swift APIs within Django APIs? So very first reason is that it hides the technical requirements from the end user. The user doesn't need to know what all parameters and variables need to be passed to Swift to access or store data on OpenStack Swift. Secondly, it acts as an interface between Swift and Sunward. As Ritthi already discussed that our storage portal that is our storage, Swift storage can change with any other storage. So whatever changes are there, these will not be reflected in the client in the Sunward client or our client can also change. Our client can be Sunward or telemetry or it can be deployed for any other client as well. Thirdly, our API processes and forward started to the cloud storage. Like whatever request we receive from the user, we make some changes and we perform some processes and finally we send it to the Swift API and we receive the response and we send that response back to the client. Then our API allows inbuilt authorization. So if a user is already authenticated, he does not need to go through the pain of authorization by generating authorization tokens because our API that we have created has an inbuilt functionality of generating those tokens. So any registered users or any authenticated user can get direct access to the data. And finally, our Django API is allowing the storage to be generated in nature. Like right now we have deployed it in a learning context. It can also be deployed in a non-learning context where the management system has the hierarchy similar to the Swift storage hierarchy of accounts, containers and objects. Like it can be deployed in a banking management system where the account can be the customer organization. The containers can be the individual accounts and the objects can be the data of each user. So this is the list of the APIs and their functionalities. These APIs are performing crude operations on the containers and objects. Like we can upload an object, download an object, update metadata, delete containers and objects. So you can see the URL here is in the same form as the hierarchy of the Swift object storage. Like our URL signifies accounts then containers and objects. So now we have a small demo video. This video will show some of the APIs that we are using. So right now we are trying to get the list of containers in the Swift account. So we see this is the list of all containers. These represent the courses in the LMS. Then we want to see the list of objects or the content in the chemistry folder. So right now it is empty. So what we do, we try to add a new object. We upload a file in the chemistry folder. It is choosing a file. So it has selected a PNG image and now it is sending the request to the Swift through our API. And now when we check the list of objects back in our chemistry folder, we will find that the image has been successfully uploaded. So now we can also view and download that object or image. So this image has been uploaded. About our learnings. In technical, we have to learn about Python and Django REST framework thoroughly because we have implemented our API using the same. And we also needed to learn about OpenStack Swift because our API is interacting with the Swift object storage APIs. And in non-technical, we learned how to work and coordinate as a team because all of our tasks are interdependent. And there were times when our code would not work out, so we never gave up. And we kept on browsing and ultimately we figured out a solution to make our API work. About future scope. Currently our API allows only single upload of objects. So maybe it can be extended for allowing multiple uploads. And right now we can upload only PDF, PNG, JPEG, mp3, mp4 and zip files. For uploading files of any other extension, we have to put them in a zip file. So maybe it can be customized for uploading files of other extensions as well. Now, Badri will give a presentation on Docker containerization in Sunbird. Good morning, everyone. I'm Badri Nag. Today I'm going to discuss about how we have used a Docker containerization in our Sunbird platform. As they have created the Django API to support our local cloud storage, we have to use that in our Sunbird platform. So for that, we need to deploy the Django API in our Sunbird platform. There are... So I'm mainly discussing about three points here. How we have deployed the Django API in our server and how we are making code changes and we are rebuilding the total Sunbird platform. And why the need of private registry instead of Docker API here. First thing, yeah, there are so many ways to deploy our Django API and we have used the containerization technique to deploy them. As Sunbird platform is highly distributed and uses containerization technique to deploy, we also use the containerization technique. So for that, we need to Dockerize the Django API. For that, I have written a Docker file such that it should run the Django API in our server. As this Docker image is very small size, we just upload into the Docker Hub and we pulled into our actual server and the container is running here as you can see. But in our daily development process, we are making changes every day and we are rebuilding the total Sunbird image and we are pushing into Docker Hub and we are again pulling into the actual server. But due to some network problems, we are unable to push and pull to the Docker Hub. So it slowed up our development process. So from there, we came with an idea of Docker private registry. So instead of Docker Hub, we are pushing our image through Docker private registry. From there, we are pulling to our actual server. So it really speeds up our development process. But Sunbird platform by default, it uses to download the image from the Docker Hub. For that, we need some changes in our code such that making some changes in the Ansible files so that it will use our private Docker image. In coming to my learnings, as Sunbird uses containerization technique, Docker is one of the tool and it was some part of Sunbird platform is written by Node.js. There is a need to learn Node.js. And also we have created APIs using Django. There is a need to learn Django. And after the installation, we have tested every API of Sunbird using Postman tool. And we have learned one best thing is how to Dockerize an application, which is very important one. And as you can see, our team is of 14 people. I have never worked like this before. And it was a great experience to me. And coming to my future scope, as you can see, we have modified only a few things of our Sunbird portal, which are the main functionalities, not modified so many things in the background process. And later in the future, we can also do that. So after deploying the API in our server, how the API is added to the Sunbird API, Mr. Srikant will explain this. So I'm Srikant and I'll be explaining about adding roots in the Kong API gateway. And first I'll be explaining my contribution to this project and then the learnings and the future scope. And so what is an API gateway? So an API gateway is responsible for request routing, composition, and protocol translation. So Sunbird uses APIs extensively for all, like creating courses each of its purpose. And it is all these APIs are routed through Kong. So how to add a new root for our storage API? So there are two ways to add an API to Kong. One is the manual way, where we will be sending a post request to the slash API's endpoint with the required parameters like name of the API, the request path, the upstream URL, which is the actual endpoint of our API, and the strip request path. And there is another automated way which uses Ansible. So in that we will be adding a new entry in the Ansible playbook for the Kong task. And then we will be running the Ansible role so that the new added API can be onboarded into the Kong. So while doing this, there were many learnings, like I got to learn how Kong works, how API routing is working, and a lot of our Kong plugins and authorization plugin in Kong, and how to automate tasks in Ansible. And non-technical aspects are like how to work with the team and how to gather the confidence to work on any new or complicated project. And future scope, like so far after the API was containerized and we have added it to Kong, so we have not set any rate limit for our API. So if it, for platforms deployed on large scale, there will be a large number of requests coming in. So future scope could be adding rate limit so that it will be all right. And then load balancing also for when there are large number of requests. And then routing according to consumer type, like mobile users can get one, routed to a separate URL and like this for desktop. And now I'll, Ravi will be talking about organization and user management. Hello everyone. I'm Raj Chandra. I'm going to talk about organization and user management APIs and type of roles for the users in Sunbird. In Sunbird, they have provided a facility for the users to work as an organization rather than individual. And each user can be assigned a task in this organization. Based on the task, they'll get specific content rights. This is the list of roles provided in Sunbird. And these roles can be assigned to the users using the organization user management APIs. These APIs require two tokens. One is bearer token and other is user token. The bearer is provided during, in the key clock of Sunbird. And the user token is a unique user ID provided to the users. And this is the list of user APIs which are used to create users as user. And this is the organization APIs which is used to create organization and assign roles to the users. Using these APIs, we can assign roles to the users. And I learned about, coming to my learnings, I learned about REST APIs, the features of them while using Sunbird APIs. And all the data about the users, organizations, and the roles will be stored in the Cassandra platform. So I had to learn about Cassandra and how to make queries in a Cassandra database and everything. And I, I used an API testing tool called Postman to test these APIs, provided by Sunbird. And I've never worked with a team before. I have worked with 14 people here. I learned, learned about teamwork. And I developed the confidence, confidence to learn new things and to work on complicated projects. Now, Prakash and Harshit will talk about content flowing Sunbird. I am Harshit and he's Prakash. We will just discuss about, discuss about the content flow because the Sunbird was not well documented. So we just study how the code was, how was the code flow. Hello everyone. I am going to explain about the different types of content available on the Sunbird platform. The first one is the book. Book is the collection of different types of contents. And it is mainly created from the school books. Course is nothing but it is a sequence of the contents. Resource. Resource is the simplest part of any content. And mainly it is the methodology for teaching. And the collection, collection is the compilation of the contents. And the most important part for the collection is that the related and the unrelated data can be compiled together. And the lesson plan. Lesson plan is the structured outline which any tutor uses for teaching the any topic or chapters. Upload content. Upload content is used to uploads any of the contents which we have created offline. Coming through the code flow. Harshit will explain. So when we were studying the code flow that was not well documented. So we all studied the code flow. So we have just studied the code flow for the creation of the course. When the course is created, when the user is required for with the role of course creator. And when it starts creating course, a pop-up comes with a page including in this using the AngularJS concept of ng directives. And when it clicks on the start creating button, it goes to a function which take all the information from the previous page and generates a URL that will throw it to the create content API. And when we will go to the create content API, it will means when we go to the content service, it will pass through app.js that will redirect it to the middlewares. In middlewares, there are two middlewares, proxy and request middlewares. In proxy middlewares, there are three functions in which one function is for the just validate the request body that is coming from the API. And one is for the validate all the tokens. Like we have if we want to use an API, there are various tokens required. So this function just validate all the tokens required for the API. And then it there is one more important function which that is hierarchy update which store all the metadata related to the course. All the metadata of this course is stored in a variable that is hierarchy. After then it goes to a step because of the code complexity and unavailability of some course of sunbird, we are not able to know how the data is transferring to a step. So after this we just save user just save the course and then it transfer to course reviewer to review the course. When course reviewer review the course, it just it will have two options it can request for changes to the creator or it just can publish. So when it will publish the course will again save and a function is called which just change the URL to the content content, publish content API. So that it will publish the content. And when we just click he will just click on publish button, the publish content API will call and all it will store all the metadata and it will just transfer the whole data to a step platform in the form of ecar file. So Prakash now will tell what is the ecar file. Hello everyone. All the details of the contents are stored in the ecar file format in the ecar step platforms. Basically ecar means ecar step content archive. Actually ecar stores all the files in the g formats which includes the manifest.json file. And in the manifest.json files it has the metadata about the contents like the name, description and the version types. And also it contains the relative parts to the resources. Next Harsil will explain about the learnings and the future. There was too many learnings for us like we have understand the structure of the large project because we were just working of code flow. So we learned various techniques used in that project like AngularJS, NodeJS and we were just going through different containers of Docker. So we just learned Docker and we have learned various things about APIs working in Sunbird platform. And we also learned how important is the documentation for a project because there was no documentation. So we have faced lots of problems. And in non-technical absolutely we have worked in team of 14. So that was lot of learning in working with team because whenever we have to study code flow then we were just dependent on Ravi so that he can create different type of user for us. And patience was also the key because there was too many times we were stuck in the code. And in future we will say as I have mentioned earlier we were not able to understand all the code flow. So it requires more understanding and the code of content and editor of Sunbird will be available in the 1.7 version of Sunbird. So it is also required to study it and like I have said we have just study the course flow of generating course. So we can also understand how the other contents are just created. So that's all. Now I will talk about the storing course data on the Swift storage. We knew that Sunbird sends content related request to Xtrap and Xtrap process is that request in its own way. So I studied how the course content is sent to Xtrap and how Xtrap creates those ECAR and ECML files. ECML is just like ECAR it is Xtrap content markup language. After getting a point where Sunbird sends request to ECAR we were not able to exactly understand how ECAR or ECML is created because that is the proprietary of Xtrap. And some part of the code was not available. So at that point we just send the course metadata to a Swift storage and for that we used the Swift, the APIs which were created by other teammates. My technical learnings from this project were to how to understand the open source contents. I learned how REST APIs worked on Docker and I also learned Node.js. About non-technical learnings, I learned how to respect what others are doing, what others are thinking and how to accommodate myself with them. Futurescope, we can create ECAR or ECML file at our local platform if we get some part of code when it becomes available. And after that instead of storing just course metadata we can also store the whole course content on Swift. Hello again. Now we are going to talk about local storage for courses. The new section added on the Sunbird, we are fetching the content now. Initially the Sunbird were fetching content from the Xtrap. Now we are fetching content from both Xtrap and the local storage we have created like Utkars have mentioned. So this is the new section added where we are showing the content of the Swift storage. Now clicking on any course it will show you the detail of the course. This is also our own custom format of showing course. This is just a basic structure. And also we have added this course creation form where you can create a form with course name and description and the subtopic of the courses. This is just a basic format. This can be improved in the future. And these are the APIs of these are new courses. So the front end part is explained by Pradeep and the courses that are being shown in the Sunbird portal. The content that are coming that are fetched by these APIs, calling these APIs. We have created APIs like GetCourse API, GetObjects API. This in return will make a request to the Django server we have created. And they will again do a request to Swift to fetch all the courses. And finally we will display it in the Sunbird portal. So we have made GetCourse API which will display the list of courses. Then GetObjects API it will give you the description of that course and the objects that are there inside. This GetParticularObject API it will on clicking on a we have got a list of objects that are present in our course and clicking on that object we can view that object. And this API is working behind that thing. We have API like DeleteObject API. It will delete a particular object inside a course. Then we have CreateCourse API. It will take a multipart form data as a request in request body. It will contain the title of the course, the description of the course and the files that are going to be uploaded inside. Then we have a DeleteCourse API. So the challenges that we have faced for adding this course API we had to study the already existing code inside Sunbird. That was a real challenge for us because it was really tough to get all the codes. The JavaScript minification problem this was the major problem we faced because when we build on one machine and upload it on testing on another machine while building it was minifying all the JavaScript files and store it in single file and import it in the index.ejs file. So what it was doing with Angular was that in Angular we have to map all the scope functions, locations and HTTP to one variable. So during minification it was not able to map. So we didn't implement the mapping function. So after adding that mapping this was working fine. And transferring file? We had also issues in transferring file from Node.js to Django server. We had previously done transferring of only text data but this was the first time I have transferred huge files. So there was a problem of encoding. We were stuck in this. We didn't know how to properly send a file from one server to another. And we had also come across this multi-part form data. Using this multi-part form data along with text we can upload files. So we didn't know this. We have also learned this. So in learning while editing the code and making new changes, we have got better understanding of Angular.js and Node.js. And also we have learned how to work in teams because the team we were making the Django server they have also cooperated and understood the problems that we are having. So because of the time limit we have also missed some of the things to be implemented. So these are the new things that can be added in the already implemented stuff. Reviewing the content, we have not implemented rating, editing and adding the bookmark. Adding bookmark is already done in the existing courses which are faced from the x-step, not in the courses which are faced from ITBX storage. So that's all from us. And these are the links where you can go and check out our details about the projects and our contributions. They had one tougher problem because unlike most others where teams of three or four, they are a team of 14 or 15, right? So why is it that the teamwork is not a part and parcel of our conventional education system? This problem has, I mean, bogged us down for a long time. You all must be participating in larger activities as teams, right? For example, in IIT, the entire Mood Indigo, for example, or TechFest is completely organized by students. And the number of students who participate in that organization is upward of 200 to 250 people. Now, every year there are a few oldies who have broken their bones in the previous years and a large number of new people. And they learn team management on the fly. But there are certain things which can be included in our conventional educational system. We don't seem to have any scope because almost all courses that you study, you have to study on your own. You have to appear for exam for your own. And you get marks only individually. So do you think this kind of teamwork could be sort of institutionalized in some sense? I mean, this is a generic observation I'm making. I'm sure that all of you would have learned some more things about teamwork. They are emphasizing it because they are the maximum problems being a very large team. In coordination between different teams, so some part you have to organize hierarchically and some part differently. You know, in our MOOCs offering last year, we tried this. I don't know if some of you were involved in those courses. We offered some skill courses. JP Morgan gave us some funding. And we offered courses called soft skills, workplace communication, and financial literacy. And we found that some of these aspects, actually the feedback from the students who attended was very useful. We'll be extended. Unfortunately, we run it only under blended MOOCs programs. So that means these courses will be offered only to those students who are studying in colleges which are our remote centers. I don't know, many of those colleges are our remote centers. Perhaps we have not done that mapping. But this is something that I have told Professor Anil Sasarov, also that at the AICT level, they should include some of these aspects as part of the regular BTECH B curriculum. And team learning, team management, I mean, we're all smart people, so we learn to work in teams. But many times, by the time we learn how to effectively participate in team work, the event is over. And therefore, that formalization does not happen. I was just curious as to why did you pick up on Swift as a replacement to Amazon or S3 services, is it? Sir, major thing was that Swift was, the first of all, since both the platforms we are working on, Open edX and Sunbird, they are open source. So that's why we considered open source as a better option. No, no, no. I agree. But our own cloud storage is also open source. Sir, actually, we were not sure whether it will work or not. So this was just a prototypic process that we followed. We first implemented it on a low scale. That's why our future scope was like we can implement it on a large scale. Because we were not sure whether it will work or not. The integrations will work or not. Currently, the OpenV storage, so actually it has an object store as well as a file store. But OpenV storage. But it does not have Swift-like APIs. Yes, but for our own offerings, whether Open edX now, that is IIT Bombay, or future Sunbird or whatever it is, I think we need to ensure that our cloud also provides similar APIs of this type. So one possibility is we implement Swift on our own VMs. But that will cause an additional overhead unnecessarily. You have to use something, and once you start using something, then you figure out problems there. But by that time it is too late to choose something else. And had you chosen something else, who knows you might have faced more problems there. That is life, by the way.