<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Snehanshu Phukon</title>
    <description>The latest articles on DEV Community by Snehanshu Phukon (@psnehanshu).</description>
    <link>https://dev.to/psnehanshu</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F202625%2F1aaaa01d-8b82-4364-9729-1f1e451a773d.jpeg</url>
      <title>DEV Community: Snehanshu Phukon</title>
      <link>https://dev.to/psnehanshu</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/psnehanshu"/>
    <language>en</language>
    <item>
      <title>Why is it called XMLHttpRequest?</title>
      <dc:creator>Snehanshu Phukon</dc:creator>
      <pubDate>Fri, 02 Jul 2021 18:13:54 +0000</pubDate>
      <link>https://dev.to/psnehanshu/why-is-it-called-xmlhttprequest-1h00</link>
      <guid>https://dev.to/psnehanshu/why-is-it-called-xmlhttprequest-1h00</guid>
      <description>&lt;div class="ltag__stackexchange--container"&gt;
  &lt;div class="ltag__stackexchange--title-container"&gt;
    
      &lt;div class="ltag__stackexchange--title"&gt;
        &lt;div class="ltag__stackexchange--header"&gt;
          &lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--AoTUKOcU--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev.to/assets/stackoverflow-logo-b42691ae545e4810b105ee957979a853a696085e67e43ee14c5699cf3e890fb4.svg" alt=""&gt;
          &lt;a href="https://stackoverflow.com/questions/12067185/why-is-it-called-xmlhttprequest" rel="noopener noreferrer"&gt;
            Why is it called XMLHttpRequest?
          &lt;/a&gt;
        &lt;/div&gt;
        &lt;div class="ltag__stackexchange--post-metadata"&gt;
          &lt;span&gt;Aug 22 '12&lt;/span&gt;
            &lt;span&gt;Comments: 1&lt;/span&gt;
            &lt;span&gt;Answers: 3&lt;/span&gt;
        &lt;/div&gt;
      &lt;/div&gt;
      &lt;a class="ltag__stackexchange--score-container" href="https://stackoverflow.com/questions/12067185/why-is-it-called-xmlhttprequest" rel="noopener noreferrer"&gt;
        &lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--oeieW07A--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev.to/assets/stackexchange-arrow-up-eff2e2849e67d156181d258e38802c0b57fa011f74164a7f97675ca3b6ab756b.svg" alt=""&gt;
        &lt;div class="ltag__stackexchange--score-number"&gt;
          75
        &lt;/div&gt;
        &lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--h2-sXgSn--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://dev.to/assets/stackexchange-arrow-down-4349fac0dd932d284fab7e4dd9846f19a3710558efde0d2dfd05897f3eeb9aba.svg" alt=""&gt;
      &lt;/a&gt;
    
  &lt;/div&gt;
  &lt;div class="ltag__stackexchange--body"&gt;
    
&lt;p&gt;I always wonder why this object is called like that?&lt;/p&gt;
&lt;p&gt;The body of your request does not need to be in XML format. Also, data received from server can be fetched as JSON, XML, HTML, or plain text. XML does not play an essential part in this object. Is this…&lt;/p&gt;
    
  &lt;/div&gt;
  &lt;div class="ltag__stackexchange--btn--container"&gt;
    &lt;a href="https://stackoverflow.com/questions/12067185/why-is-it-called-xmlhttprequest" class="ltag__stackexchange--btn" rel="noopener noreferrer"&gt;Open Full Question&lt;/a&gt;
  &lt;/div&gt;
&lt;/div&gt;


</description>
    </item>
    <item>
      <title>What is Open Charge Point Protocol?</title>
      <dc:creator>Snehanshu Phukon</dc:creator>
      <pubDate>Tue, 28 Apr 2020 19:33:35 +0000</pubDate>
      <link>https://dev.to/psnehanshu/what-is-open-charge-point-protocol-3c5n</link>
      <guid>https://dev.to/psnehanshu/what-is-open-charge-point-protocol-3c5n</guid>
      <description>&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fkqkewid4dowfrggdgr62.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fkqkewid4dowfrggdgr62.png" alt="OCPP Illustration"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Originally posted on &lt;a href="https://www.snehanshu.tech/electric-vehicles/ocpp/2020/04/03/what-is-ocpp.html" rel="noopener noreferrer"&gt;my blog&lt;/a&gt; (April 3, 2020)&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The &lt;a href="https://www.snehanshu.tech/electric-vehicles/tech/2018/06/14/electric-vehicles-in-india-and-why-they-arent-already-here.html" rel="noopener noreferrer"&gt;Electric Vehicle&lt;/a&gt;, or EV for short, is the new kind of vehicles that will slowly phase out the traditional petrol and diesel-based vehicles. The pros are immense - environment friendly, low maintenance cost, low sound pollution, etc. The only major con is the availability of public charging points. Although this is improving with every passing day, there is still a long time before an average buyer will become confident enough to choose EV over a traditional vehicle.&lt;/p&gt;

&lt;p&gt;Traditional petrol pumps are very simple, there are human-operated machines that fill the tank of the vehicles, other than showing the amount of fuel filled and the cost, it doesn't have any functionality. But EV charging points were designed to be smart from the beginning. Features such as card-based authentication, remote control by charge point operator, remote configuration, smart grid-based charging are very common.&lt;/p&gt;

&lt;p&gt;With this feature set, there comes a problem, the charge points are tightly coupled with the backends (dashboards that operators use to remotely control the charge points) due to proprietary protocols. This means, if an operator buys a dashboard, then he can install charge points of only those brands which the backend supports. This is a problem. To solve this issue, there needs to be a standard protocol, which has to be open-sourced, and must be followed by backend vendors and charge point vendors to enable interoperability. That's OCPP.&lt;/p&gt;

&lt;p&gt;OCPP or &lt;a href="https://www.openchargealliance.org/protocols/ocpp-16/" rel="noopener noreferrer"&gt;Open Charge Point Protocol&lt;/a&gt; is a protocol that was designed by &lt;a href="https://www.openchargealliance.org/" rel="noopener noreferrer"&gt;Open Charge Alliance&lt;/a&gt; as a standard for communication between a charging point and the backend software.&lt;/p&gt;

&lt;h2&gt;
  
  
  Versions of OCPP
&lt;/h2&gt;

&lt;p&gt;OCPP has version &lt;a href="https://www.openchargealliance.org/protocols/ocpp-15/" rel="noopener noreferrer"&gt;1.5&lt;/a&gt;, &lt;a href="https://www.openchargealliance.org/protocols/ocpp-16/" rel="noopener noreferrer"&gt;1.6&lt;/a&gt; and &lt;a href="https://www.openchargealliance.org/protocols/ocpp-201/" rel="noopener noreferrer"&gt;2.0.1&lt;/a&gt; till now.&lt;/p&gt;

&lt;p&gt;OCPP 1.5 is officially based on &lt;a href="https://en.wikipedia.org/wiki/SOAP" rel="noopener noreferrer"&gt;SOAP&lt;/a&gt;, but there are also unofficial implementations based on JSON-over-Websocket. OCPP 1.6 officially supports both SOAP and JSON-over-Websocket. OCPP 2.0.1 officially supports only JSON-over-Websocket.&lt;/p&gt;

&lt;p&gt;To avoid confusion, the version numbers are always suffixed with an "s" or "j", which respectively mean "SOAP" and "JSON-over-Websocket". e.g. ocpp1.5s, ocpp1.6j, ocpp2.0.1j etc.&lt;/p&gt;

&lt;p&gt;I'm not a big fan of SOAP, I will write down some disadvantages of SOAP from the top of my head.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;SOAP uses &lt;a href="https://en.wikipedia.org/wiki/XML" rel="noopener noreferrer"&gt;XML&lt;/a&gt; to represent data, which is very bulky, not good for charge points which may have unreliable internet connectivity.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;SOAP requires both the backend and the charge point to act as servers to facilitate two-way communication. This is also bad because it eliminates the possibility of operating several charge points behind the same router, because to become a server, each charge points will require unique IP addresses, which is costly.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;SOAP is an old and outdated technology invented at Microsoft. Modern developers don't bother learning it (including me ;-) ). If your solution is based on SOAP, you may have a hard time finding good developers.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Therefore I am not going to discuss how the SOAP versions work, because neither do I know. JSON-over-WebSocket versions overcome all of the above shortcomings.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;As the name suggests, it uses &lt;a href="https://www.json.org/json-en.html" rel="noopener noreferrer"&gt;JSON&lt;/a&gt; to represent data, which is way much slimmer than XML.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;It relies on &lt;a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API" rel="noopener noreferrer"&gt;websocket&lt;/a&gt; for two-way communication, which requires only one entity to act as a server, which in OCPP's case is the backend.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;JSON-over-Websocket is a very modern technology and most modern apps already use it. You will find plenty of good developers.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Creators of OCPP also realized their mistake, and therefore the latest version only supports JSON-over-Websocket.&lt;/p&gt;

&lt;h2&gt;
  
  
  Let's talk about WebSocket
&lt;/h2&gt;

&lt;p&gt;Websocket is an advanced protocol that works on top of &lt;a href="https://developer.mozilla.org/en-US/docs/Web/HTTP" rel="noopener noreferrer"&gt;HTTP&lt;/a&gt;. Traditional HTTP is client-driven, which means it is the client who initiates a request and the server only responds. The server cannot send any data to the client without the client requesting it. It made sense in the early days of the internet when websites were mostly static, but think about modern apps, like &lt;a href="https://www.messenger.com/" rel="noopener noreferrer"&gt;Facebook messeger&lt;/a&gt;. Whenever someone sends a message, the server needs to notify the client of the receiver to display the new message on the screen without reloading the page. Before the advent of WebSocket, developers used a little hack called &lt;a href="https://www.pubnub.com/blog/http-long-polling/" rel="noopener noreferrer"&gt;long-polling&lt;/a&gt; to achieve the same functionality. The client will keep requesting the server for any updates at a fixed interval of time. If the server has updates, it will immediately send those updates as the response to those requests. If the client received any updates, then it can act accordingly, i.e. show the message on the screen. But the disadvantage is that it is not that realtime, and if you reduce the interval, then there's a danger of overloading the server with too many useless requests.&lt;/p&gt;

&lt;p&gt;Therefore WebSocket was invented. Here, the client still needs to initiate the connection and do the handshake, but once that's done, a two-way tunnel is created in which data can flow in both directions independently. The client can send messages to the server and the server too can send messages to the client.&lt;/p&gt;

&lt;p&gt;Coupled with JSON, it becomes the perfect solution for OCPP, where the charge points act as clients and initiate the connection, and the backend acts as the server. No need to worry now, install as many as chargers you need behind that router, WebSocket got you covered!&lt;/p&gt;




&lt;p&gt;That's all for this post. I will write about the technical details on how OCPP with JSON-over-Websockets functions, and I will also post some code examples about how to implement OCPP using Node.js in the next post. So stay tuned!&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
