loctv

HTTP Streaming (or Chunked vs Store & Forward)

The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.

However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on

loctv

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD

loctv

Default

Powerlevel9k

loctv

WITH recursive dep_tree AS (
  SELECT mdl0.id, mdl0.name, NULL::integer, 1 AS level, array[mdl0.id] AS path_info
  FROM ir_module_module mdl0
  WHERE name = 'sale' -- state here the child module 
  UNION ALL
  SELECT (SELECT mdl1.id FROM ir_module_module mdl1 WHERE mdl1.name = c.name), rpad('', p.level * 1, '_') || c.name, c.module_id, p.level + 1, p.path_info||c.id
  FROM ir_module_module_dependency c
    JOIN dep_tree p ON c.module_id = p.id
)
SELECT level, name

loctv

In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

• query
• mutation

Reference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.

loctv

server {
        listen       80;
        server_name  example.com;
        root /www/example;
        access_by_lua 'denyip()'; #check error counter 

        error_page  400 404 405 406 = /404.html;
        location = /404.html {
                set $inc 1; #this is useful for blocking website scanners
                set_by_lua $err 'incerror()' $inc;

loctv

#!/bin/bash

# * Defaults

compression=xz
subdir="web"

# * Functions

function debug {

loctv

Keybase proof

I hereby claim:

• I am loctv on github.
• I am loctv (https://keybase.io/loctv) on keybase.
• I have a public key ASCpVx1Hoju78aE2Qjavn1B93pDEFgpy5FmPnys6vyDTUAo

To claim this, I am signing this object:

loctv

loctv

#!/bin/bash

# CONST 1GB

CONST_1GB="1024*1024*1024"

# VARIABLE WORKERS

CMD_W=0