 The concept behind my talk is a lot about JavaScript and Intent of Things. So JavaScript is like a fully functional programming language with prototypical inheritance. Internet of Things, as you all know. Let me just throw an insight into what my talk is and what is the principle behind connected devices. So Internet of Things does not simply imply having a device which is connected to the internet or having a device which simply has a hardware. So the principle behind connected devices is you ensure a physical circuit or an embedded circuit has a full function and that is being connected to the internet for a purpose. So an example can be for the connected devices for physical sensors. It might be heartbeat sensors, gyros or accelerometers and ultrasonic sensors. So the talk is mostly two parts. The first part is about what the IoT should offer and how are you planning to integrate JavaScript with IoT. And the second part is about Project J IoT. Let me come to that part later. So the first point is all about how am I planning to integrate JavaScript with Internet of Things. Let us suppose you have a hard disk or a flash drive which has a media content. So in order to make sure that the content is available to all your clients or if you have a measure to serve the content to all your clients, you use the concept of media service. So media service is nothing but streaming your file content to the users and whatever be the type of the content, be it an MP4, be it an MP3 or be it an image, you serve the content to your client. So there are fundamentally different concepts of media service but let me skim it down and say the most noted points. Your media service should handle the CRUD operations and it must have endpoints which supports the get, the post, the delete and the options. Apart from that, let me say how am I implying to connect my concept of media service with Internet of Things. If suppose I have a big CPU or a big machine, a desktop machine and if I am planning to start the hotspot and if I am planning to connect, if I am planning to enable the content to the users for whoever is connected to the hotspot, then that is like a very tedious job because you have entire big physical space being occupied. So the concept of connecting IoT with JavaScript plays here. So what I am planning to do is if you have a Raspberry Pi or if you have a Galileo, if you have any single board motherboard circuits, then you can actually run an operating system and you can run a CRON. So as soon as the system starts, you can have a CRON running which starts a hotspot and whoever is connected to the hotspot, you can pipe the local host to the connected client. So what I am implying here is let us take a use case scenario. Let us say that I have Raspberry Pi which has a Wi-Fi module and as soon as the system starts, the Raspberry Pi operating system starts, I start the Wi-Fi and whoever may be the client, whoever may be connected to my hotspot, they can have my content serving. They can view whatever content I have and depending on what I am planning to serve them, they can actually view them. So the process of going through how to write a bigger server and how to do that, I think that is available in Google. It is not so difficult. You have to ensure some things. One is writing your script for executing the start of the CRON and apart from that, you should also make sure the system as a whole functions foolproof and it does not allow unknown support and mind-pipes to download as soon as you process a request. I know I am a bit technical there but let me explain what I am meaning there. First of all, the whole concept of media servers is based on browser-based requests. So if you have a browser and if you are posting a request like play this particular MP4 file or play this particular MP3 file, as soon as the moment you post the request, the request is being taken by your media server. You process the request and you play whatever media which the user is willing to see. But the point is if you have an advantage, you have a challenge. The advantage is the very fundamental concept of having HTTP 304 within your stack is you can support the content which is not being modified and route it and serve it to all the clients who are being connected to you. So with a minimal caching mechanism and with a minimal meme cache mechanism, you can absolutely serve any big file or any file which you have in your media, like which you have as your media content. So the point is not only supporting most of the CRUD operations, you should also support the concept of mind-types. So mind-type is the content type which are willing to serve the people who are connected to your media server. So if you only support this particular file, that is actually a bad notion because if your media server is only limited to this particular scope, then you don't have a win-win situation in order to upgrade the module because the point of writing your own media server is you have to write modular code. That is one point. I'm sure I didn't mention the point of go, but in Golang as well as JavaScript, you have the very fundamental modules, the HTTP in Golang and the HTTP module in Node.js. So the point of writing your own media server is not adding fancy modules to your application and loading your application because all of the JavaScript community agrees to the point that NPM is the largest ecosystem. NPM stands for the Node Packaging Manager. NPM is a large ecosystem. We agree to the point. But when you have a number of useless packages and fancy, fancy packages for each small purpose, then the whole point of having those many modules does not serve it. So using the code modules to the fullest and using the code modules in order to write your media server is actually a very good notion, point one. Point two, we agree to the point if you have a big media content like as in if you have large mp4s, if you have video files which are very large in size, obviously the ability of your media server to serve your content is not flawless. So in order to make sure you serve flawless content, point one is using the HTTP protocol 304 to the fullest is one point. Point two is how are you using a caching mechanism? If it comes to Node.js, it is Vanish since the dog is mostly JavaScript related. Vanish is one package where you can actually add a mechanism in order to serve the caching for your media server. So the point in that is mostly about how are you supporting your media server with different mind types, point one. And how are you supporting your media servers without using the third party modules? Like if you have most of the third party modules within your application, then you have a lot of dependency issues because if the module breaks, whichever module you are depending on, the module breaks and you have to ensure your code is not depending on the module. So the fundamentally you have to write your own endpoints, be it a get endpoint, be it a post endpoint. You have to write your own endpoints which are dependent on the core modules. So that is one point we should actually note. And then before I say this, let me make sure, I don't know whether this is part of good practices, but let me make sure these are few gotchas which you have to make sure while you are writing your own media server. One is we should not depend on Node.js or Node's primary engine to define your own headers. If you run your own server and you are counting on Node to define the headers for you, then it is actually a very bad piece of code because if you have an unknown mind type or if you have an unknown URI, as soon as the moment the URI is being opened, it automatically prompts you to download. You might have observed this if you open your browser and you open an unknown file type like a .data file or .obv file, automatically the moment you open it, it prompts you to save file or open with. So you have to ensure that this particular thing is not happening. So I agree to the point that you should support a large set of mind types and you should write your code modular in such a way that if you have a new mind type which you are willing to support, then you should add it. I agree to the point. But depending on Node to implicitly define headers for you is not actually a good notion. You should actually explicitly define your own headers and in order to ensure this thing is happening, you can actually have a very small hack for this. One is have a .csv file within your repository and the .csv file can contain all the mind types which are willing to support it. And if the .csv file has all the supported mind types, upon each request posted by the user, have a regular expression matching of what the request is and skim down the JSON in such a way that take the content type header out and whatever is unknown content type, don't just allow the user to download it. Instead go for a 404 or post message saying that this particular content is not supported by a media server and please check go back to the main directory or something like that. The point there is don't prompt the download each and every time. That is actually a very good notion because it is part of good practices. I failed to, I did not mention most mechanism part like how this thing fits you best. Before I dive into that part, let me make sure what I am implying with additional media server concept. So at the start of the talk I mentioned about Internet of Things. So the point here is you have your own Raspberry Pi or you have your own inter-Galileo or you have whatever is the single code motherboard. You have your system, you have your operating system running, you have your Wi-Fi module which is attached. You start your hotspot, the clients are connected, you serve the media with your media content, you serve the media with your media server and whoever is the client who is connected, you can actually use the concept of caching as well as reverse proxy. So let me say how this can be helpful. Whoever is the client who is connected to your hotspot has an IP address which is defined by your DNS which is part of your media server. So as soon as the moment you have your DNS defining IPs, if your application is running on your local host, you can actually enable the person to view the application which is running on your local host. So if I start the application or the media server within the Raspberry Pi which is running on local host 8080 or whatever be the port, that particular thing can be routed to the user each and every time he opens the browser. So with minimal configuration in that part, you can actually have this particular thing being added to your media server. That is one point. And as far as I mentioned the concept of reverse proxy, let me also extend this in saying that caching is a very good mechanism because serving your content is one point and caching the content is the later because if you use the concept of meme cache or if you use the concept of the readers being part of this, you can actually ensure the application is not bloated and as well as the media server is not having a bottleneck situation. That is two points. One thing which I mentioned about media server is you have your IoT device and the whole point here is connecting your hard drive. So if you are aware of this, each and every time you have a hard disk being mounted, you have that being gone to a directory, be it slash sda or be it something. So each and every time you connect to USB or each and every time you connect to hard disk, you randomly have a mount point. So if you have this thing fixed to a particular mount point and you don't know how the next connected hard disk might be mounted at, you are actually writing another part of a bad practice. So in order to ensure that thing is not happening, you can actually go to a directory in ETC. If you go to the directory ETC, you have a file called fstab. So at this point, you have the options wherein you can specify the mount point. So here, the whole of the media which is running on the GNU or Linux based operating system is mounted to the directory called media slash media. And there, if you define your own directory like media, whatever be the name of the directory, if you define the directory and depending on the UID of the SSD or your hard drive, each and every time your hard drive is being mounted, you can direct that to that particular mount point. So here, you're ensuring that you physically, within the aspect of your application, you know where your media is being mounted. It is not like you do not know where the media is being mounted. So that is one point we should have to ensure while writing that. Okay, let me come to the second part of the talk. It is called Project J IOT. It is an open source project. It is available on GitHub. I'll provide the link at the end of the talk. So the point of having a media server like all is one point. You have a lot of media servers. You have many open source organizations which have their own set of media servers running. So how this thing is different from all of them. So one thing is there is this concept called WebSpeed API. Okay, so JavaScript does not provide or JavaScript does not support the whole concept of WebSpeed API still ES5. As the rollout of Atmoscript 6 started, they started supporting with the minimal experimental features of the WebSpeed API. So the WebSpeed API is nothing but supporting speech recognition and supporting speech synthesis, speech grammar, speech list. So the whole point where I'm hinting at here is if you have a media server running, you have an application which is running and whoever may the user be, if suppose he posts a voice call saying that play this particular file, you can actually take the voice request of this and you can have your fixed dictionary or fixed thing wherein you process the request or if the file is available, serve the content. So the point of using WebSpeed API is you are minimizing the job of the user in order to traverse the directories or traverse whatever be the large file content is and you are allowing him to view the content in a better way. So let us say this is better part of a UI UX concept or let us say you are providing him at ease of use to view the content. That is one point. Second, as I mentioned this thing is an experimental concept. This is not supported for all the browsers. It is only supported for the Chrome as well as Firefox. Although Firefox does not support a continuous function. It is only supported for the 44 and the Chrome for the 33. So as I said it is all about writing your own API and having endpoints in your API in such a way that you process the request and depending on the request, serve the content. If it is not available, force for a 404. So entire thing is being linked to the previous thing. So this particular thing, the WebSpeed API concept is just like a module which is added to the previous application. So that is it. I guess I am pretty much done. If any questions are there, I guess I am done. Guys if you have questions, please ask. We have still have time. I still have time. Ask questions offline if you don't want to ask.