dikini.net

HTTP is a stateless protocol. This fact has confused and tripped many aspiring web developers. Mostly stateless. It was stateless until Netscape, back in the misty days of 1994, baked cookies and released them for public consumption. Later the Internet power mind, IETF, published the standard baking recipes in their RFC 2109, followed later by RFC 2965, titled "HTTP state management mechanism".

The standard is clear and straight forward. Not surprisingly, it is a translation to network protocol language of one of the most widely used approaches of pure functional programming to managing state - when you have to care about state, thread it. In this post I'm trying to transcribe it. For my amusement, public confusion as well as for brevity I will use haskell like notation when trying to present the modelling of the utility of the http cookies as a carrier of the http state.

• basic http
• stateful http
• opaque state
• state size matters
• just waiting for the end

I've been looking more into haskell, as part of some personal projects. There I need some constant array like structures, that is ones which have integer indexing and there are some long winded reasons I'm not using a Map. As a first step I've decided look at haskell arrays, by writing some search functions. It is mostly a syntax exercise.

During the drupal plugin/update manager discussions I had an aha moment. One of those weird and wonderful ideas came back to me. What if most of the code lived in the db? One would be able to arrange the co-habitation of several concurrent versions of the same website relatively easy. Backups would mean database backup.

Funnily enough, this can help two opposite (scale-wise) types of users - the bottom end, cheapest or free hosting ones and the load balanced crowd.

Why "back"? Well... I had this idea ever since the user streams appeared in php, version 4.3 or there abouts, but it just nestled cosily in the back of my mind, waiting for love, the shy little thing.

• the problem
• the benchmark
• results
• conclusions

I'm on a learning haskell journey. But reading someone else's code and thoughts while educational is not that enlightening. Anyway, to cut the long story short:

• I (still) want to see what this haskell thing is all about
• I need a moderately complex problem to get a feeling of the haskell type system works, face the dreaded IO, while not wasting too much time
• I need a decent actor style abstraction for some social/population based methods experiments I'm into

So this is how ended with Why not try my hand at erlang style concurrency. The best thing about it is that it aligns nicely with an individualistic view of the world. I can write sequential code to do something, which from time to time communicates with the rest of them, while the rest of the time doesn't really care.

Erlang implements lightweight processes with asynchronous messaging. The cool twist it puts on it is having reception guards - if a message is not matched by the guard conditions it stays in the mailbox (channel), and the rest of the messages are scanned. The first matching message is removed from the mailbox, the remaining messages are left in the mailbox in arrival order.

While reading, researching and experimenting for my macros project the terms in the title get mixed a lot. I'll try to summarise what is my understanding of a lot of the above. To be fair, most of these words are heavily overloaded with sometimes contradictory and or ovelapping meanings, so this short is only about my personal summary, no pretence for a general study or lit review.

Generic programming intuitevely corresponds to design patterns, or a tool to implement them. There should be a distinction between the functional or algorithmic side of the term and the structural or data (type) genericity.