It's Soleta, an open source project that is trying to fix, to close the IoT development gap. Who am I? IoT development gaps, what I mean with that? How to close them? What is Soleta, the project aiming to close them? It's key subsystems, flow-based programming, our development tools, and also future plans. So who am I? I'm a Brazilian guy. I'm a software developer since I was nine years old, so I think about software, that's how I think, right? I don't think in Portuguese or English, I basically think about coding, because that's what I did for most of my life. I started to work with Embedded in 2005. I didn't do real, what people call real embedded systems by the time. I did Maemo, the Nokia internet tablet platform that was just born. So it was already a new kind of Embedded, because it was nicer in hardware, in memory. It wasn't microcontrollers at that time. And I created Profusion, a software development services company, which I run from 2008 to 2013, five years. When I sold this company to Intel, Intel bought my company, and I'm now out because I wanted to recreate my own company. I'm very passionate about efficiency, so you can find me in lots of open source circles. All are related to some kind of efficiency. So Soleta is one, I'm also trying to help with Zephyr. I'm part of the Enlightenment Foundation Library's development. And I am the Soleta architect and lead developer, a role that I started while I was working at Intel, who created this open source project, and I'm still keeping that, okay? IoT development gaps, what are them? So, while I was a manager at Intel, I had the task to investigate IoT development. What is it? How to do it? How is it different from traditional Embedded systems that we are mostly used to? And this, after some research, it wasn't obvious at first, but IoT is different from traditional Embedded systems. If you look at Embedded systems, they're small, they're there, they're measuring stuff, they're putting some data, like factors have IoT forever, right? What's the big difference? What's the new thing now? The new thing is that everything in the world moving towards faster pace. So, by the time that we did Embedded, or the old guys did Embedded, and it was very hard, you had to plan your hardware for 10 years, 15 years, maybe more, you had a huge and long development path, and deployment path, because you had to choose carefully all your bond, your build materials, pick all the hardware, create something that is not expensive, and that will last, and you did your product. So, you took care of the whole software stock. If there was a kernel, libraries, and your own software. But then, phones started to change the whole picture, and nowadays people develop phones and web applications in all time. They can ship one application in like one month from zero to out, to be selling. And that's what is expected about IoT. Of course, people expect more data because data is proven to have a value. With Facebook and Twitter, that was clear. So, all the big guys wanted to have a stake of that, so they want the data. They want, for example, Amazon wants to know about your data, so they can put together a package of lights, light bulb, and send to you so they can make more money, and they can help you. It's not all of the bad, all of the, I want to take your money. It's far good. But that requires a different pace of development that we didn't have before. So things like, are you put together my Yocto system because I will compile my whole world? Are you put like 15 guys to develop these, just the last base, plus my application? It's not what IoT is about. It's about faster.  Okay? However, the solutions are focused only on a single subset. For example, Intel has two projects, right? One is MRAA is a library to access sensors like GPIO, I2C, and so on. That's just harder. Zero knowledge about networking protocols. How do I integrate my GPIO to my network? Like IoTVT is another project that is just about the network part and one network part. How do I do IoTVT with MQTT with MRAA? It is a pain, right? And most of them don't cover the basics of the system. So things like, I want to create a software update and I want to deploy that. How to do it? How do I trigger my software update? What is my software update? It all depends. Depends if you created with RPM, with Debian and so on. So for the guy that is coming from a web or phone where they had a clear API, where they could use, then it's a big change, right? And most solutions are platform-specific and are not scalable. If you think of the base libraries, for example, Glib, QTEFL, they won't scale down. If you saw the keynote, all nice, you can draw flow charts, that's JavaScript, big JavaScript. It's not going to run on the JavaScript microcontroller. That is supposed to run on a PC that controls multiple devices. But how to write those devices? It is a pain, right? Nothing is integrated and it's very hard to reuse your knowledge. Unlike before, right now you may have a team, a single team of five, six guys, that is supposed to create the microcontroller and the general proposed CPU of the same product, like a combination, a dashboard and lamps, a router and some network devices. So it's very hard to reuse. You keep having to ping across technologies. You have to learn how to do Linux, how to do Zephyr, how to do all of those technologies and you lose time. And time is important right now. More importantly, in this phase, because nobody knows what is IoT, so everyone is experimenting. They are releasing products, they are expensive, they are cheap, they do lots, do fields. So what is going to stick? They are trying to cover it all? See what sticks. So time is very important, right? So we have these needs. We have the need for faster development cycles, much faster. I'm not talking about years, I'm talking about weeks of development cycles. Like, start this project now, I want a proof of concept in the field to be tested in three weeks, okay? They should cover multiple product families, like microcontrollers, gateways, multi-core CPUs, and I'm not sure if you're familiar with the microcontroller operating systems, but Zephyr is the only option right now that offers you the same support on various boards because it provides subsystems like the Linux kernel. If you have Contiki or Riot or other OSes, it's not, I know Contiki, I know Contiki for a given board because even the base APIs like TPI or ITUC, they change based on each board board. So this is a nightmare. And of course, a low, small engineering teams and we want to easy the development choices. I know from the 15 or more HTTP client libraries in Linux, which one to pick? But do you all know of each of the audio, video, and all these libraries, do you want to invest time to learn? Ever seen? You just want your product out. You don't want to do lots of, do diligence investigating all of the libraries and how to put them together because I find that I should be using Libco, okay? So nice. I found that I should be using IoTivity, very nice. How to make them work together. It's very hard. So we had to create a solution that provided a uniform API that would work on multiple platforms, right? So I'm doing HTTP on Contiki. I'm doing HTTP on Linux. My code should be the same, right? I shouldn't have to write two, three files for two, three platforms. We should focus on three areas that are important for IoT that is basically IO. So you have sensors, actuators, communication because as in the keynote today, the protocols are not standard. It's not an industry standard still. So you have people doing MQTT, MQTT sensor network that is UDP. You have IoTivity that is still in flux. You have people doing HTTP. So people doing Bluetooth. What should I use? It's hard to pick one now and stay with it for years. So you should have an API that makes it easier for you to have them all or transition between them, okay? And also OS services. They think like, how do I persist my data? On Linux, you open a file, that's it. How do I do that on Zephyr, on EPROM? You don't have a file system in there. So you need a solution that helps you and take care of that for you so you can focus on your development. This API should be easy to use and should be scalable, as I said. Microcontrollers and up, okay? So that was the trigger to Intel at the time, my team, to create Soleta. At the time, it was called development application. It was DevApp at the time. Okay, Soleta is an open source project for real. It ships with an open source license that is Apache 2.0. Why? Because some microcontrollers you need static linking. So GPL wasn't an option, although I'm very, I really like GPL and LGPL. And it is a real open source project. You can go to GitHub and see the huge work that we are doing all in public. I left Intel and I still work on reviews and all. So it is a real open source project. It's not version two big code drop, big patch. It's all incremental. You can send the pull requests and it's all in there, all in public. It's portable code. It's multiple OS since day one, okay? Day zero. We started with Linux, micro Linux and Riot at the time. Then we added Contiki and Zephyr, okay? This micro Linux is something that is very interesting because some people look at solutions on how to scale down. Like people said in the keynote today, four megabytes is pushing too much. Okay, it is pushing too much on Linux. However, if you change the way that you look at your user space, you can get there. For example, what if instead of having busy box, a shell, a script, then your application, what if you made your application, they need it? The PID one. It would be much linear. Yes, that's what we have in Soleta. You can just compile Soleta differently, stack link it into your application and your application will be the whole user space. You can create a need to run a fast with it and that's it. You need no shell, you need no busy box, you have no licensing problems and it will do things much better than busy box. For example, it will auto mount, it will mod probe if you need models and it will bring up IPv6 network for you, things like that. It should support many boards. As you can see, most of the boards here are Intel boards because we were majorly developed by Intel but it is not a blocker to support other boards. Raspberry Pi was very easy to support. Atmel is the one that we run Riot. Arduino 101, we also run Zephyr and Contiki. Our code is Scable. However, it's too easy to use. It's like portable object oriented coding C. And we ship with event-driven programming to abstract the OS specific from the user. There is nothing more annoying to a high level developer, guys coming from phones or from web and do the development for free or toss and you are called from the ISR, the Interruption Services Handler and suddenly you cannot do what you were supposed to do. And the OS is very small. However, you, the developer, have to carry all the burden to make your code run for real because I'm called back from a GPIO Interruption. Very nice. Now I will do a network access. No go. Your code will not work and you will not know why. There's no way. There's no like, oh, segmentation fault. Volgrine, GDB, let's backtrace this. This is nothing like that. So it is very hard to disguise that are coming from a different point of view like Swift, Object C, Node.js. That's why we have projects like JavaScript trying to solve the same problem in a different way. Okay, and Soleta is also very modular. We allow you to compile Soleta with different features enabled and disabled. That's why we use the K config, the kernel config system, instead of Autoconf. We started with Autoconf, but we wanted to allow all the fine-grained and the dependencies were becoming a mess. So we changed it to K config. It works much better. You can control for Zephyr, for example. I want GPIO, but not I2C. I want HTTPDs and not Bluetooth. Soleta is composite about some subsystems. It looks like a kernel, but it's not. It's what, we define Soleta as what is your user space? So on Linux, it's clear, but for Zephyr, it would be the Zephyr user space. Although there is no actual separation, it would fit the same role. For example, you do very low level stuff, where, in the kernel. And high level stuff, you do in user space on Linux, right? So that's the separation that we do also on other systems. The three most important are input and output, communications, and OS services. But we also have persistence, machine learning. I will talk more about that later. Input and output, we do ship with low level APIs, GPIO, analog IO, I2C, SPY, UR, PWM. Although we ship with this, we don't recommend you to write drivers on top of those. Those are just for a quick prototyping, testing, and so on. The actual drivers and actuators, for sensors and actuators should be in the kernel. So people like UPM, another Intel project, going with MRAA, try to do that in user space. And with that, it comes problems. Sometimes you need real time behavior, sometimes you need a faster response. Don't try to do that in user space. Do that in the kernel, right? Use all the kernel primitives, but expose that nicely in user space. So on Linux, we have the industrial IO that we use extensively in Soleta. And on Zephyr, we help it to create this, like, my team was part of the ideas to define this sensor subsystem, but we still didn't port to it yet. It's on our roadmap. OS specifics are abstracted. You do have a callback for our GPIO event, but it's not a real time front interruption. It's queued for you, it's called from a safe environment. You can do whatever you want from there, okay? So we abstract that from you. For communications, we have all the important IoT standards. We have MQTT, that's the HTTP version. We run on top of Mosquito, so it's a Linux only library at the moment. We have the HTTP server via micro HTTPD on Linux, and nothing on the microcontrollers. And client, we do ship with curl support. So we do curl, including server-side events, so you can get real-time feeds without having to pull the server. We have lightweight machine-to-machine, that is an industry standard. And OIC, or OCF, what is implemented by IoTivity. We have our own implementation based on our own implementation of co-app. So it works everywhere where you have UDP, right? And these allowed Soleta to be the first implementation to support both server and client of OIC. Because when people were designing solutions, they were thinking like, I have a light bulb, I have a switch. None of them are the server. Or actually, in their case, both of them are the server. The client is your iPhone or your gateway. So you need the third party to control two simple things. Why not make one the server and another one the client? Because there was no implementation for that. And they thought it wasn't possible because of hardware constraints. We did it and we proved it was possible with careful written code, okay? So we have this mantra to choose wisely and integrate well. So be HTTP or MQTT, the code is not the same because the technologies are not the same, but they feel the same. So if you were doing HTTP, you want to try another protocol, it should be not a big learning curve, okay? The APIs are the same. They use the same patterns and the same, the API concepts, reference counting and everything. And we also ship with OS systems. Basically, it's an area that is ignored by most projects. Like how do I trigger my software update? Like phases like check if there is an update, fetch and apply. I'm not saying that Soleta does all of that because Soleta is just the integration part. So we do have systems for Linux, but the idea is that people would implement the backends and the application developer wouldn't care. So I want to check if there is an update from a timer, from the booth, from the internet. You execute this call you got if there is an update or not. I want to fetch that update and have some progress of that. I want to apply that. So it is an API that is very simple. It should be implementable on both Zephyr, Riot and all the other systems. We have ways to stop and start and monitor services. So our Linux implementation is based on system D so it's very dynamic. You don't need to pull, it's very lean. But we also have that concept implemented in MicroLinux PID1 because you may have a service in concept although it's inside your own process. But it's a service to start the network and you want to monitor the network using that link. That's okay. Power supply, enumeration and monitoring. So do I have a barrier? Do I have a AC power? Are they connected? How much is left? Basic things like I want to reboot or enter rescue mode. How to do that? With system D you have a target. How to do that on Zephyr? I would have to look and research. With Soleta, the idea is that we provide that for you. You just have to use it. And we also ship with a network connection manager. On Linux it's based on common but it should be implementable everywhere. It's very simple in concept. I'm not trying to replace like network manager gathered on Ubuntu. I'm just trying to say, list me the services. Please tell me if the internet is connected or not. And it's dynamic. So you can know if the internet was disconnected or connected. It's something that is missing from most of the technologies. We also have other subsystems that you as a developer are free to use. We have that type, it's very simple. List, array, buffer, slice. We have logging with domains. So you can choose which area of your application you are going to show the logs. And you can also disable that log at compile time. You can compile out the log. We have a parser for JSON because OIC uses that at the time. But you're not required to use that. There is no code in our side that requires JSON at runtime. We have persistence to file EFI variables for traditional x86 boards. And EPROM, we create the virtual file system for you. So you give me a map. It is a JSON file. I will convert that map to a C table where I know people want to save the password. So password is offset 15 to 32. So that's my available space to write the password. And it will ensure EPROM is written to disk. And with all the nice, it's queued so you don't write as much. So you wait a bit like that. We have worker thread so you can have low priority preemptible work whenever possible. We have crypto certificates, message digest, like SHA or MD5, things like that. And encryption is still to do. We don't have any need for encryption at the time. And we also ship with machine learning. So it's called so data machine learning that implements fuzzy and neural networks. It's not the algorithm that is implemented. We integrate third-party libraries but make them easy to use. So when you come and you say, I want this light to be on when I am in the room and it's day, should be easy to learn that, right? Let's use a machine learning algorithm. You will use lots of time just to understand how fuzzy or a neural network works and to define the project and all. So we try to make that easier for you, okay? With the machine learning, that's the idea. So a checklist. Looking at Soleta today, we have a Uniform API. So the API is there since day zero. We had the three main areas and more and it was scalable. But we had to test if it was easy to use, okay? And we started to do some trainings, workshops and all. However, that is pure C. Main loop, something that is not common to every developer, okay? And it's based on callbacks. So call me back when the GPIO has an on or off. Call me back when I2C has some message. Some guys don't get that and the code starts to leak or start to crash, right? Most users don't get it. So it's hard. People, particular people from web, they expect the system to manage the memory for you. With Node.js, they created this promise concept where you can change like load file, then, then, then. It's super easy to use, okay? But then you come to C and it's a nightmare. If you have to change multiple, like read data, like read this I2C, couple of messages, then you have to change it all. After that, you do some network, then you have to change that. And at some point, the user cancels the operation. Then, which phase I am, how to break that without leaking memory, it is a nightmare. And usually, when it's not a nightmare, it's a boring pattern. Like, oh, I was called to get the new data and do something. Is there a way to make it more easier to use? Yes. As you saw today in the keynote, the flow-based programming is a new trend, right? It started on web with Google TensorFlow and things like that. But the idea is that you don't think about each function. You think about macro blocks and how they exchange the information. You don't think how the information is done internally, just what gets out. For example, take a look at this flow. It's a very basic flow. Suppose you want to control an action to be triggered every x second. From two configuration inputs. You want a dial, like a physical dial, that may be a I2C or whatever. And you want the HTTP server to take HTTP requests. So you expose a webpage, like a printer, right? You expose your webpage and user can go and say, I want 15 seconds. How do I make all of them integrated, persist to this or whatever, and execute? It's pretty simple in flow. You have a dial. I don't know how this dial is implemented. Just get one input part that say x, that is an integer. And when it changes, it says there is another x, right? There's another value of x. And the same from HTTP.  If it's a simple post. All that matters is that. When people ask me what's the current value, I will return it. And when the value changes, I want to be informed. So it's pretty simple. However, here you see a closed loop. For example, if dial changes, it's going to persistence. Persistence will write a new value and send a new package, which will go back to dial. The naive code, if we're doing plain C, the naive code will just, like, fault. Because it will enter a loop, and the recursion will explode your stack. With the flow programming, you have total control of that. So this is not going to happen. Because you are not growing on the stack.  So it was a concept invented by J.P. Morrison in the 70s. So it's very old. It was used by some banks and some IBM systems. The idea is that each component or those boxes, they are black boxes. You don't care or know about them. And they are isolated. They don't share any context with each other. They are just defined by their idea and their output ports or input ports. So what gets in, what gets out. The focus, like myself as a developer, I don't have to focus on the boxes. I focus on what the boxes are exchanging with each other. So focus on the information packets, or IP. In Soleta, we call them just packets. It started to gain traction on the web. You can see no flow is a big one. It's a big player based on OJS. They have a UI to draw it. You have Facebook Flux, Google TensorFlow, Microsoft Event Hubs, and also on embedded systems. If you look at ROS, they are using that. You have the ROS, the Robot Operating Systems.  This is the camera recognition. This is the self-balance. And you use that. Microfoil is also another good solution. And Node-RED, is this a good solution that you could see today? However, it doesn't scale down. How do I do a microcontroller with that to down? That's just what goes in the hub where you are going to control. Multimedia is also very pipeline and flow-based. So even video for Linux, but also Gstreamer and the Apple Quartz are using flow-based programming. They are not using the same language or the same terms, but the same abstract concept. So Node has black boxes. The interface is pretty simple. I have instantiate, destantiate, like a constructor-destructor, and some ports. Each port has three functions, like disconnect and process if you're incoming data. If you're outputting data, it's just connect and disconnect. If you want to know about that information, like I was connected or disconnected, it's very easy to optimize because you can remove ports. It's like if you could remove the methods of an object.  But in FVP, it's simple. And as we don't have a real runtime, it's not like a virtual machine. We are just c-code. If you don't take the pointer to that c-code, the garbage collector of your compiler will remove that section. And it is also very good for parallelization. If you have two, three, four cores, and I want to use that, each box is independent, right? You can put each box in a process or in a thread and run it. All the core needs to do is you take the packet and deliver in the same thread as the other node is running. So if the core takes care of that, it could be done. So let us not doing that, but it's something that we always think about. And also, isolation. Information is all that you care. So if you want to isolate, like I have this complex machine learning from a third-party company, and that machine learning isn't supposed to reach the internet, right? And it's just supposed to take five megabytes of RAM, not more. I don't want that to pollute my whole system. This is a binder that I got. I don't want that to pollute my whole system. So what do you do? You will spill that to a different process and use some kind of serialization. You are good to do that because all that you need to know is about the packet. If the packet is simple, like an integer string, whatever, we have an automatic code to do that. Otherwise, you can write that yourself. But the idea is you can do it as a single and then move it outside or inside as you wish. And internally, each node, each black box can use threads, can use a main loop, doesn't need to, it can. The only thing is that they output the data or and take the data they were supposed to. So what's an FBP example? We had this FBP before, let's make it real. You see that very little things change. At the left, this is our domain-specific languages based on no flow with some extensions.  It's being created from a type called myDylerType that here doesn't matter. I will talk about this later. And then you have HTTP server that is based on this HTTP server slash int. That is, it will serve an integer when you post or when you get. On the path, you time out microseconds, you have also persistence of integer. So it will write to a file called time out microseconds because I said storage FS. And we have a default value, that is 10 seconds or 10,000 microseconds, milliseconds. And we have the timer and the action. So I just created the boxes, they're dangling. No connection between them. And now I create the connections. The language is pretty simple. So we have dial output port called out. That is the yellow arrow. It's connected persistence. So it's very, although it is not graphical, we don't have a graphical user interface to design that. It's very easy to do, it's very easy to map, right? Any questions in looking at this, like very small example? But the idea is that you can use this to create the new node types as well. So you can make these your whole application, but you can create, make these part of your application. So you can create boxes of boxes, okay? There are pros and cons. The cons, the paradigm shift, it is hard. Particularly on old and experienced developers, it is hard. We start to think like I wasn't aware of FBP when we started. We did all you see, and then we got this problem, we found a solution. We started to eat our own dog food. Lots of mistakes. Particularly when you try to synchronize things that shouldn't be synchronous. So you have one node that's sending package to another. Then you have another one that is sending. You want to synchronize both methods.  No.  Then your first idea is to fix that. You create a new hop here just to delay the package as well. And this was the biggest mistake that we ever did. While we were learning. Why? Because that box may take one cycle. But that box may be composed of 15,000 boxes and that may take 15,000 cycles. You don't know. You can't know. So it was a big mistake at the beginning. It takes you time to learn. However, this paradigm shift, it's easier on new developers. If you have a circuit electrical engineer, he gets that fast. If you have people that are new to programming like early students in the university, they get that fast. But us like use it to do things in C, procedural, we have some problems with that. I won't lie to you. And although it's small, it does add some overhead. I will show the numbers later. But it is very small compared to all that you see. It is small. And we are not talking about heavy optimizations like in the previous talk in this room, we have JavaScript, where they are encoding multiple information in one point or in one single world, right? Here we are doing no kind of optimization. So we could do that, but we are not doing at this moment because we don't need. We are already working nice on all the target boards that we have. Okay, and the other problem is if you want to use a third-party library, like this new protocol came out and I want to use it, how to do it? You have to write a binding. So you have to create a node type that expose that library as input and output ports. And this is some work that people don't expect. And you also need balance on what you do in FBP and what you do inside the node. Clear example, when we started to do the FBP, we started with the easy nodes, right? And or add, sub, multiply, things like that. And then let's write a Fibonacci. But it's very simple to write a Fibonacci in C. It should be very simple to write a Fibonacci in FBP. It is not, it is not. It's not nice, it's not efficient. Why? Because it shouldn't be there, right? What is the idea of having, you could have a Fibonacci node that is in C that is very simple, that takes one number outputs to the next one, I don't know, things like that. So you need to be careful to balance what goes as FBP and what goes as in C, okay? However, there are big pros and that's why I'm here talking to you about the FBP, okay? No leaks or segmentation faults. If you are providing software to your customer, like my company, Profusion, we had to provide libraries so our customer would create the actual software.  Hey, Gustavo, there's a bugging in your code. Here's the backtrace, like double free, but then you see your library code in the bottom. So if there is your library, it is your fault. It doesn't matter that your library just called his function, his function did the mistake, but it is a problem. It's like I have problems like this inside Intel, inside other companies as well and it is a nightmare that if possible, you want to avoid and with the FBP, you can avoid that easily. On the other hand, it's very easy to create thin collaborations. Like if you go back to this, like this one, what is dial, my dialer? It doesn't matter. All that matters is that it's something that takes an integer, sends an integer. I can outsource that my dialer type to a different company. Meanwhile, I can use another HTTP server to simulate my node. In Soleta, we do ship with some simulation nodes, like we ship with GTK. Then we have a GTK spin button, right? Whenever you create this, like instead of my dialer type, you can write GTK slash spin button. It will create a window with a spin button with the value. When you change it, it will go and put some package on the output port, and when it takes, it will update. It's very simple. Then it eases the collaboration with different teams, right? And also eases the specification because you're not specifying like 15,000 methods.  And about this possibility to just care about the input and output ports, you can easily change your hardware. Like in this board, I want a GPIO pin one, edge low. In that other board, I want a USB keyboard. How to do that? I would have to rewrite my code because USB handling is one way, or keyboard handling is one way, GPIO handling is another way. But here, hey, give me some saying that whenever it's action happens, it will output true or false, something like this. Okay, so it's very easy to change, which is very important if you go back to my first or second slide, where we say that you must support various hardware because people are not doing one hardware for 15 years anymore in IoT space. It's very easy to read, to write, and to visualize. We don't have an editor, a visual editor, but we generate graph viz, so you can create the visual representation. And it's fast to prototype and test because as you have a narrow surface, you can start to do fuzzy testing as you wish. It's very simple. We started to love FPP because of testing. It made our testing much easier. Okay, so show me the size. We had this Intel Quark SE development board running Zephyr OS. This board is like 192K of flash, something like this. Is that the actual numbers? 80K, right? Yeah, so RAM was 80K on this board. It's a very small board. So Soleta plus the OS plus IPv6 plus OIC and PIO and timer, it took us 107K of flash. 32K of RAM. If you take all their solutions, like the JavaScript that was in this room before, it is very nice. They're doing amazing job, but there are limits on the technology because you have to do parsing. Here, there's zero parsing. It's not seeing, when you generate the code that you show you later, you are not dealing with any numbers or names. It's like, you're not dealing with output portals. Let's find the output port out. No, it's an integer that is an index in an array. So it's all one. It's very fast. It's very small and it's very lean. And developer tools. To help the developer just having the language and just having the C API is not enough. We had to create some tools. They are still in early stages and one of the areas that we need more development. So we have some Python scripts or C tools to generate code for us and to the user to reduce the burden. So we have the OIC or IoT with your OCF as a wish. They publish the specifications in JSON. So we can create an old type based on that JSON. So if you look at them, they have bright light. Bright light has like power, intensity, call or whatever. We generate both node types. We generate the client and the server for you. And they have input and output ports of each property with the correct type. So this is amazing, saves lots of time. And we also have ways to generate the flow node type. So I want to create my own company IP. I will create my own flow node types. So we have a tool that takes a JSON, generates the code for you. And we also use that JSON to generate code in the second, the third tool that is the FBP generator. Because you don't want to interpret that text file in your microcontroller, right? You want to read a bunch of JSON that saves which node is what, what ports, types. Then you create an array of connections and it's very, very small. It's like two tables. You have one table that defines our nodes. In this example, you would have a table with one, two, three, four, five entries, right? The five entries, they would be composed of a pointer to the type and a pointer to the structure like timeout and URL. This is not a string that is parsed at runtime. We convert that to a real C structure for you. And the name like dial. So it's a very small entry. And the second table is composed of all of these connections that is basically integer, integer, integer, integer, integer, integer. So this is the integer of the first table and this is the integer inside this table. So it's very, very fast, very, very small, right? And you can grow as big as you want. What is actually adding to your project is the implementation of your node type, but that's in C. And that is supposed to be done by experienced developers. So it shouldn't be a big of a concern. And as the interfaces are pretty well-defined, you can rewrite them without hurting the application. So you can start with a naive implementation, then you measure, you see it is too big, start to cut and the overall flow doesn't change. And then we have this dev app. I had the name and I had to put the name in some project, so I used the name in the development tool. It's a web-based IDE written on Node.js and Angular. It can and should be executed on the target. So the idea is that when you buy a development board, it comes with a card and a manual of instructions to go to my website, download my Eclipse SDK. Like two gigabytes later, you'll find out that your Ubuntu version is not compatible or you are running Arch Linux and not Ubuntu or Fedora. And you have pros. What if we could ship boards with the SDK inside? So you plug in the SDK card, boots, and it's there. You use Avahi or some XeroConf to find a board and you open it. There is a text editor. You do what you need, execute. It runs on that board. It is something that is very nice. Compared to the today's keynote, which run in a different instances, like it's running on my laptop and this is running on the actual board. This runs on the board, right? It includes assistant D journal viewer so you can see all the logs, not just logs from your application. So if Wi-Fi is struggling to find something, you are going to see the WPA supplicant in there or seeing that some demon died, things like this. We have built-in documentation so if you are doing a hackathon and you don't have access to the internet, you can still find what you need. We have a text editor with syntax highlight, including FVP and the code completion. We have the FVP runner that can execute it there. We have an inspector that can give you a glance of the packages that are being exchanged. So it's kind of nice. And we have this viewer in Graphics. And the idea is that you can try Soleta right now by taking a supported board, you're plugging the image that you can download and that's it. You don't need nothing else. You don't need a putty or some kind of tool on your Windows PC, right? It looks like this. The dark colors doesn't help in this room, but they did that have a tree with files on the left. Whenever you click then, you're going to have an option to edit then with a syntax highlight, like this is an FVP with a mistake. So we have the FVP runner well integrated. So as you type, it's going to check and say, hey, you have a mistake here. It's missing an error or something like this. Okay, and we also generate the chart that we plotted at the bottom. You can hide these panels. You can clone a different GitHub or a different Git repo. So here, closer pictures. So in the top, you can see the syntax highlight and error, error. At the bottom, you can see the system D log. So there's a demon like NPD, NTPD, and have policy key to have the FVP runner and you have the chart of the right. So before I end, we have some future plans as this is a community project and we are here community. If you want to engage with the project, be as a user. If you want to use it, drop by our channel. It's Soleta at FreeNode. Drop me a mail. I'm kind of very glad to help you guys to use that and try that. I can explain the basics. We can set up an online IRC or Skype, whatever meeting. But ideally, we need more Node.js bindings. So we started to be usable from Node.js. So Node.js would use GPIO I2C from our API. The idea is that you can convert a Node type to a JS object, pretty simple and pre-automatic. So you don't need to create bindings for each of the libraries. You can automatically load all the Node types. We also need Python bindings because it's a language that we like. We could use a fancier web inspector. We have a nice one now, but it could be even better. We need a visual editor. We started one, but nobody completed it. So it's there, but not usable. We wanted DevApp to generate, to cross-compile. So we wanted to use like Bigelbomb Black to generate images to an Atmel with Riot and would flash it and would run it. Okay, so this is something that we would love to have. And we have the concept of FBP meta types. So instead of manually typing a type, you give it some information, it will create a type for you. So we want to have the lightweight machine to machine, OIC and also Bluetooth flow energy. We could improve FBP size when static linking and use more mempools to reduce memory allocations and also port to the most common IoT board out there that is the ESP8266, okay? And then based on that's it, I have more information about flow-based programming in my talk later today. It's at 5.10 in the afternoon. So if you want to know more about what is flow programming, the drawbacks and all, stop by. And first question, anyone, first question? Okay, so, okay. Okay, so I can summarize that to everyone as this kind of a fragmentation problem that leads to the same solution in compatible solutions to the same problem, right? Is that it? What you meant? Yeah, so I see this problem in two ways. First, a way to guarantee that it's conformant and they play well together. For this, there's one side that is like the openmax problem that you basically don't have control so there's no way to fix it. On the other hand, the way that we try to do it in Soleta is to first, always think about the most common stuff because we have some packet types for flow. We don't have just like integer and that's it and you have to do whatever else you want and then the first company that needs a tree like a direction vector, X, I, Z, will create its own packet and then it's incompatible with everything else, right? So what we did is we tried to put as much thing in the core that could be usable by most parties. So caller, we have things like that. And to avoid the fragmentation, what we would love to see is some kind of NPM repo where we could actively put stuff and also monitor stuff. So the most used should be part of the core whenever possible. So that would help to reduce fragmentation. And the other side of seeing that is how to like let the user work around that problem is as you're just based on the basic flow and like packet types, you can easily encapsulate P in C or with another FBP a way to convert from one to another and keep the overall structure the same. So this guy outputs things in a float and you need an integer, so you throw out the precision. You can do that. And you can do that in C as well, right? But from our experience, even that is easier with the FBP and that's why we are pushing for it. In C, it's a bit more problematic because the C is more flexible, right? You can create different methods. The methods can have different behavior. Like you can do a thread and you have to implement an observer object. I can do a callback and he can do like a different process. And my callback will fire at some point, your callback will fire a different point. To the user, this is a nightmare. But as you reduce the exposure, it's like you are just meant to act when there is a callback or a packet, right? So it's easier for you. You know when you should use that data. And this is what we believe it's very good in FBP and that's why we are pushing it. So it doesn't automatically fix the problems, but it improves a bit on top of plain C. Second question, so we can finish. Someone with a second question, last question. Do you want to ask another one? No. Do you want to? Okay. Any further questions? Okay, so thank you guys.