First approach is feasible.

As first approach, I've developed a terrible conduit interpreter. It
turns every action into a conduit and appends it to the
pipeline. As a result, we end up with an enormous pipe which is
employed just once. Why is it so terrible?

* All the actions (chunks) are kept in memory (once for each conduit).

* This is not incremental nor continuous. Just one pass? This is a
  joke for stream processing capabilities. We're not exploiting it.

* The way to implement Get and Put is quite interesting. We're
  attaching the next component at the end of the do-notation. This is
  really ugly and not very readable (lets are not allowed!).

* This won't adapt to a REST architecture. In that situation, we don't
  know the actions until we receive them!

On the other hand, there's one good point. Now we know we can develop
a conduit interpreter without using the state monad. This is just the
starting point to create a nicer one.