Webmachine — Another painful lesson learned

Just set out to report on the nifty things I’ve learned about Webmachine over this past week only to be bushwhacked by bloody ignorance and oversight.

Justin’s quickstart docs contain this step for bringing up a simple demo web site :

./scripts/new_webmachine.erl mywebdemo /tmp

Works like a charm. But can you see implicit looming disaster?

I didn’t and here’s what happened:

I spent the week playing with different URI dispatch patterns. I wrote functions to report out consequential header variables to follow the action. I played with form input and processing. I learned some stuff and generated a few useful questions. And so, as of yesterday, I’d built up a bunch of newbie tutorial code to share on this blog. All simple-minded stuff, but possibly of value to other newbies.

Thought I’d have a lot to report today.

Not.

Can you see what happened?

Justin’s command builds the Webmachine demo in /tmp. What I’d forgotten is that certain if not all /tmp files are bombed into oblivion when you reboot the system. Guess that’s why they call it /tmp. Had to update and reboot my system today. And… guess what?

Newbie Lesson: If you want to keep your work-in-progress around a little more permanently, modify Justin’s quick start instruction just so:

./scripts/new_webmachine.erl mywebdemo ~/wmplay

Now cd to ~/wmplay/mywebdemo and away you go.

You can substitute any directory name you want for wmplay, but I suggest that you keep it short. You’ll be typing it frequently.

Note: All above assumes that you are working on a LInux platform and you’ve unpacked Webmachine in your home directory. Can’t say if you’ll run into similar issues with Windows or if Webmachine code exists elsewhere.

I do recall one pesky question that I’ll ask now in hopes that a kind wizard will step up with a revelation:

When I created a form in resource module xyz1 as…

<form name="input" action="xyz2" method="get">
<input type="text" name="user" />
<input type="submit" value="Submit" />
</form>

…and submitted it, the input value value showed up just fine.

But…

<form name="input" action="xyz2" method="post">
<input type="text" name="user" />
<input type="submit" value="Submit" />
</form>

…returned a totally blank page, even though xyz2 showed up in the URI, e.g., http://localhost:8000/xyz2.

Anyone know why and how to deal with posted input data in a Webmachine resource?

Anyway, it’s doubtful that’ll have time to get back to Webmachine until mid October. Headed off with my love on Wednesday for an anniversary week Santa Fe. Heaps to do in the meantime.

Hasta más adelante,

LRP

Webmachine — Getting to Know You 1

You know you’re getting old when you walk in on your 50th high school reunion to find wall-to-wall gray hairs.

You really know you’re getting old when it takes three days to recover from the ravages of a red-eye flight from San Francisco to Boston.

Where did all those years go? And where the vim, vigor, and vitality?

Yes, I can hear the young’uns smirking away so smugly. All I can say is, your time is coming.

Well, I’m back now and continuing my exploration of Webmachine.

First thing I noted as I eased back into the saddle was changes to the quick start page.. So, ignore much of what I said in my last post and simply follow the quick start instructions. Works like a charm for me this time around.

As I started delving deeper into the documentation, however, newbie anxieties began rising up out of the pit of my stomach. It’s all there, I’m sure, everything you need to know to build awesome websites on top of Webmachine. But some of the plain English was turning to Greek before my very eyes.

What to do? Maybe hacking out a few examples to challenge and verify my feeble understanding of the Webmachine docs would help. So, in this spirit, I decided to start with URI dispatch configuration and work my way down into more esoteric matters.

All that follows may bore wizards silly. But with all good hopes of helping along a newbie or two, here’s what I did:

At the tail end of the quick start page Justin suggests that you modify the resource /tmp/mywebdemo/src/mywebdemo_resource.erl. Rather than modify mywebdemo_resource.erl, I made six copies — res1.erl … res6.erl.

I then opened each copy and updated the module name: e.g. -module(mywebdemo_resource) to -module(res1), etc.

I also modified the html payload: e.g. {“Hello, new world”, ReqData, State} to {“Hello, res1.”, ReqData, State}, etc.

Now I have seven web pages in my demo site. But before I can access them, I need to update :/tmp/mywebdemo/priv/dispatch.conf.

Here’s what dispatch.conf looked like when I was done:

{[], mywebdemo_resource, []}.
{["res1"], res1, []}.
{["res2"], res2, []}.
{["res3"], res3, []}.
{["res4"], res4, []}.
{["res5"], res5, []}.
{["res6"], res6, []}.

Finally, I killed the Webmachine webserver, executed /tmp/mywebdemo$ make, and restarted the webserver.

So now I have a test bed for exploring Justin’s URI dispatch configuration examples.

Here’s how to access each page:

http://localhost:8000/
http://localhost:8000/res1/
…
http://localhost:8000/res6/

… but you knew that.

I’ll share my next steps in my next post.

See ya’ll.

Webmachine — Toe in the Water

As noted a few posts back, my plan had been to start developing in earnest on Nitrogen. But then, days later, I found that Nitrogen is undergoing major revision. Many moons ago Jaamal suggested that I look at Webmachine. So… what better time than the present.

The first thing you’ll notice when you link into the webmachine wiki is the crisp, clear, and inviting presentation. This doesn’t surprise me. I was fortunate to chat briefly with Justin Sheehy at Erlang Factory/Palo Alto. He definitely impressed me as a competent, no-nonsense, easily approachable professional. Both the website and Justin inspire instant trust and confidence.

I had less than an hour to play when I linked into the Webmachine quickstart page. Looked simple as pie, so I dove in.

And it was simple as pie — well, a few minor chin scratches which I’ll note below to save other newbies the ten minutes or so they cost me:

1. Make sure that you have a working Erlang/OTP release, preferably R12B3 or later.

This, for me, was the hardest step. I’ve recounted my experience in My Day Of Terror — Compiling Erlang on Lenny, August 29, 2009.

2. Get the webmachine code: svn checkout http://webmachine.googlecode.com/svn/trunk/ webmachine-read-only

First, make sure you have a subversion client on your system. I needed to download the binary from the Debian repository. Otherwise, worked like a charm.

3. Build webmachine and mochiweb:
   • cd webmachine-read-only
   • make
   • (cd deps/mochiweb ;make)

   I was momentarily confused by the function of the parens around the last step, but said, what the heck, and just did it. It worked.

• ./scripts/new_webmachine.erl mywebdemo /tmp

  The only hitch here is that the last step left me in deps/mochiweb, so I had to cd back to …/webmachine.

• cd /tmp/mywebdemo
• make
• ./start.sh
4. Take a look! Point a web browser at http://localhost:8000/

And that was it. My browser rewarded me with “hello, new world.”

Now it was time for sheer daring:

1. To make this resource handle URI paths other than /, modify the Dispatch term in /tmp/mywebdemo/src/mywebdemo_sup.erl.

   This step registered a blank until I looked back into the wiki to review the dispatch syntax. Clear as a bell. BUT, when you change source, don’t forget to kill the webmachine server (press cntrl C) then a), run make from /tmp/mywebdemo; and ./start.sh.

2. to make that resource to more interesting things, modify the resource itself at /tmp/mywebdemo/src/mywebdemo_resource.erl.

And — that was it. In less than 37 minutes I had a custom webpage.

Yeah, Justin!

My Day of Terror — Compiling Erlang on Lenny

Much encouraged by kind wizards (see Erlang — One Step Forward; Two Back; August 28, 2009; comments) I I set off this morning to compile Erlang on Reliance, my Debian Lenny workstation.

I keep trying to train myself to keep careful notes when I venture into new territory. But inevitably I get caught up in the moment and, in the end, am inevitably caught short with substantially useless historic records. Anyone else have this problem?

Just so, I’ll try to do my best to recount my experience from memory and what scanty notes that have made it through the ordeal — er, experience.

Going in, I had already copied the Erlang source into /usr/local/src and unpacked it into otp_src_R13B0.

So, first thing this morning, I followed Jamaal’s advice — just ran ./configure with no options. Scanning through the feedback I noted several packages missing: curses library, flex, lex, yywrap, odbc library, and something about a missing wx driver.

Grantmichaels implied that I could solve dependency problems with two apt commands:

(sudo) apt-get install sun-java6-jdk -y
(sudo) apt-get build-dep erlang -y

Tried the first one. System came back with:

Couldn’t find any package whose name or description matched “sun-java6-jdk”
No packages will be installed, upgraded, or removed.

Googled Debian + sun-java6-jdk — found that there was indeed such a package for Debian Lenny, though non-free. Tried to load it again, but no dice. No doubt my aging brain is missing something here.

Nevertheless I skipped on to the apt-get build-dep erlang -y step. This seemed to do a bunch of stuff that whizzed up my screen faster than a speeding bullet. So, I tried ./configure once more.

Now the system tells me I’m missing a Java compiler (can’t remember the exact note) and, again, something about a missing wx driver.

Decided to look into this wxWidgets business. Chaining through links I came to Installing xwWidgets and wxPython on Ubuntu or Debian. Followed the directions and, once again, tried ./configure — and wx driver is still among the missing.

At this point irrationality set in. Let’s go for broke. I entered make then make install and let her rip. Took awhile all the while various warnings and unknowns flashing up my screen so fast I can barely catch them in flight. Yes, I know that I’ve failed to account for a Java compiler, curses library, flex, lex, yywrap, and odbc library. No doubt my foolhardy omissions will haunt me to the end of days.

When my bash command returned, just for the hell of it, I entered erl.

And it worked!

Now, I don’t know if I have a crippled Erlang environment or not. I don’t know if or when it’ll come back and kick me in the teeth. But the Erlang shell came up and I could enter 2 + 2. and get 5.

Now, if I knew how, I’d uninstall Erlang and start over a bit more methodically. But I don’t know how to uninstall locally compiled code. So, for now, I’ll live with it.

Oh how I wish I had the skill and environment to back port Erlang R13 to Lenny. It would make it so much easier for future newbies in my position.

And thanks to the wizards for your encouragement. All dunderhead mistakes above are strictly of my own doing.

:

Erlang — One Step Forward; Two Back

A pebble in the road can loom like Mt. Everest to a newbie.

For many months now I’ve been a spectator at the Erlang marathon. Then, several weeks ago I concluded that it was time to lace up my sneakers and set off apace — that is, adopt the Nitrogen web framework and see if I could develop a serious application for myself.

Now keep in mind, I’m not a professional programmer. I can program in several languages, yes. But on my worst day I can barely boot my computer, much less turn out productive code. My best day may well fall short of your worst. So this decision to get serious about Erlang is a major step in and of itself.

But no sooner did I gird myself with resolve than I came smack up against a mountain. No — two mountains; no doubt simple pebbles from the perspective of the wizards and gurus whizzing their way down the course.

First, I found out that developer Rusty Klophaus is in hibernation contemplating a significant revision of Nitrogen. Okay, I could start with what he’s produced to date. Others have and have developed some promising aps. But what’s the profit of spending hours learning a chunk of technology when you know it’s going to be obsolete by the weekend?

The second mountain has to do with setting up an Erlang development system. I did this once on my old workstation, but may have done it wrong and have lost my notes in any event.

The problem is this:

To develop on Nitrogen I need to run Erlang R13B01 on my Debian Lenny system. The current version of Erlang in the Debian Lenny repository is 12B3 — too far back even for Webmachine. Since I can’t find a backport of R13B01, it seems I need to compile it. Shudder!

So far I’ve downloaded and unzipped the source into /usr/local/src. And I’ve read the README. If I cut through the cruft it looks like:

./configure [ options ]
make

But the ./configure options total confuse and intimidate me. So, before I shoot myself in the foot, I’m hoping that some kind soul can guide me through the process. Or, better yet, point me toward a backported Debian package.

All this was two weeks ago. Rather than proceeding apace on the Erlang course I’ve frittered away valuable time on other stuff.

Amazing how such small pebbles can loom up as major obstacles.

OTP and Erlang in Action

Martin Logan is one of the many bright people I met at Erlang Factory Palo Alto.

Martin has been programming Erlang for more than 10 years — full time for the last five. He’s the core developer at Erlware and the primary developer of the Faxien package management system.

During one of the Erlang Factory breaks Martin patiently defined “referential transparency” for me. Fancy phrase for a fairly simple concept it turns out — an expression that always returns the same result given the same input is said to be “referentially transparent.”

Anyway, I recently purchased from Manning Publications the MEAP edition of OTP and Erlang in Action by Martin Logan, Eric Merritt, and Richard Carlson. And it’s sure to be an Erlang classic.

The cool thing about MEAP is that you pop in your credit card number and get back an instant *.pdf download of the book in progress. As the authors add content, you get e-mail notification of updates from Manning. You can order hard copy of the work, of course, but you won’t get it until the formal publication date. But, I say that OTP and Erlang in Action is too important to wait. If you’re striving for professional excellence in Erlang, order both *.pdf and hard copy today.

Joe Armstrong’s Programming Erlang is, of course, the Erlang gold standard. But OTP and Erlang in Action (OTP for short) belongs right beside it. And, arguably, you might find skimming through it before you even crack open Armstrong quite profitable. Most certainly, once you’ve digested Armstrong, you’ll want to read and re-read OTP, and enter code as you go along, until the pages fall off.

OTP and Erlang in Action first leads you through the core concepts of Erlang — processes and concurrency, process communication, fault tolerance, distributed Erlang, functional programming, higher order functions, iteration vs. recursion, single assignment, and pattern matching.

All these fancy shmancy words — sounds like a trudge. But OTP is written in lucid and lively English — just the kind of plain-talk accessible language that tells you that the writers really know their stuff.

Chapter 2 introduces language basics. It’s not nearly as thorough as the Erlang tutorials or Armstrong, but it complements them nicely and, more to the point, sets you up for some dazzling hands-on programming.

To wit, the remaining 11 chapters, guide you through solid OTP production-level code — a telnet server all packaged up as an OTP application and a distributed caching system. This is code you can build and use. Along the way you learn in great detail about OTP packaging and organization, processes and linking, building a production system, distributed Erlang, tracking and managing distributed code, packaging and deployment, hot code loading and upgrading, non-native Erlang distribution, drivers and multi language interfaces — all the good stuff that was left to your imagination in other texts.

As a newbie, I’ve got to say, this book is a real find. Can’t wait for the authors to finish it.

Thinking Erlang – 3

Among the many impressive folks I met at Erlang Factory – Palo Alto was Robert Virding. Robert is a certified Erlang guru with scores of important contributions to the language under his belt. You can read Robert’s blog here.

Robert patiently answered my numerous newbie questions and, later, sent me a most thoughtful email. Here’s the gist:

“I think you are right in that one major problem with learning erlang is processes and modules, how they relate to each other.

“Another major problem for many which I will take first is the functional aspect of the language, which usually manifests itself in the lack of global data and immutable data structures. In principle this problem is easy to solve, all you need is practice and after a while you get the hang of it and then it all seems easy, natural and self evident. Everything you know is always easy, natural and self-evident. In practice it can take time to get the hang of it, and I don’t know of any good short cuts which can help. I was used to programming like this from even before Erlang so I honestly can’t remember how I initially reacted to it.

“A similar problem for many is the syntax. I have found from reading various blogs about people’s reaction to the syntax that they fall into 4 groups:

“1. They see and love it immediately.
“2. They find it strange at first but after a while they find it natural and right.
“3. They understand it and can use it but never like it.
“4. They never get it. This is most often accompanied by loud moaning and complaining about how it isn’t like the language they are used to, why can’t it be like that, can’t it be changed …

“Group 1 people are very rare and often have used similar languages before. Group 2 people seem pretty common in the projects which use Erlang, I remember Bob Ippolito said something close to this in a talk he gave when he mentioned the syntax. I can understand group 3 people although I think they are wrong. Group 4 people I just can’t understand at all. Of course it is different, it is a different language with different semantics and everything. Expecting it to be the same is at best naive and at worst plain stupid. The whole point of learning something new is that it is new and different, otherwise why do it? It is like travelling to a another country and complaining that it is different. Sorry for the diatribe but this way of thinking really gets me.

“I think peoples reaction to other aspects, like the functional side, generally falls into the same groups.

“Processes and modules.
“The way I see it modules are about *what* to do and *how* to do it, while processes are about *who* is to do it. As in the real world where you can hand out the same job to many people in erlang you can have many processes running the same code. This is allso a complete rethink for most people. In traditional systems you generally try to avoid creating to many processes/threads and you learn a lot of techniques to get around it.

“Erlang goes the other way and says create as many processes as you need.The question is then, of course, well how many do I *need* and how many *should* I use? The simple answer, which we blithely give, is as many as there are concurrent things in your problem – one process per concurrent thing. How many that is depends on how you structure your problem. This is definitely not trivial! As in real life working out the optimal number of “workers” you should have is difficult. All I can say is to try and restrict each process to doing one thing, this is usually the best, but of course sometimes some tasks just work better if they are together.

“Concurrency is definitely not easy. It also requires clear thinking in what is concurrency and how does it relate to my problem. Many times we have problems in convincing people that there is a fundamental difference in concurrent and non-concurrent objects. Just because you “send” a message to them all doesn’t mean they behave in the same way.

“Callbacks
“Callback can mean different things and can be handled differently. gen_server splits functionality into two separate parts: concurrency and some management which is handled by the library; and the functionality required by the application which is handled by user-code. It is the user code which defines what is to be done. The user code is in a module with a number of predefined functions. When an event occurs, a message arrives, the server will call a user function to handle that event. This function will do what it has to and return a value saying how it went. This is what is meant by a callback in OTP, it is a user function which called at a specific time by a server process. As the servers are generic they must handle user code and data in a very standardized way. So for example the server passes around user state in an argument to user callbacks and updated state in there return values. The server has no knowledge of what is in the state. It is the same with calling a server, the system provides some standardized ways of calling the server, that is sending request data to the server, which is then processed by the user callback and returning a result value from the callback to the original requester. The server knows *how* it is to pass the data around while the user code knows *what* to do with it.

“A final comment about your problems with inets is that you ran into many issues at the same time: what the user code is to do; how to run the OTP application, processes etc.; and how to set up an OTP application, the .app file. The last one is recognized as being tricky. Even for Joe it took a long time to work it out when writing his book, and he was one of the original developers of OTP.

“I am not an OTP expert, though I realize that I will have to learn it someday.”

Many thanks, Robert!

Seeing Erlang Anew

Mea culpa for neglecting this blog so woefully. If memory serves I was on my way to Erlang Factory in Palo Alto when I last posted. That was in… May? I promised to post again upon return from Palo Alto “…as soon as the jet lag wears off.”

Well… here we are in August. Some case of jet lag you say. And you’re right. A bit more than jet lag has distracted me from this blog and, I’m sorry to say, Erlang.

Permit me to share a bit since it does bear on the future directions of this blog.

First off, Jamaal, bless him, asked in a comment if I’d soured on Erlang. And the answer is, absolutely not! Erlang Factory was wonderfully inspirational. It gave me a much deeper sense of the Erlang community. And I was blown away by the many exciting Erlang projects in the making. On the other hand, I boarded the airport shuttle bus for home with a deep sense of humility just thinking about how much I have to learn.

Six or so hours later I stepped off the airplane and into the Boston Logan terminal with all intentions of posting my Erlang Factory encounters and impressions first thing after a good night of sleep. But something more than jet lag and less than flu knocked me out for the better part of a fortnight. I couldn’t string three coherent words together or get out of my own way. Total listlessness.

Then, just as my mitochondria started pumping out energy again I got a call from my computer hardware supplier. My new Linux workstation is ready. Good thing since Cube1, my four-year-old Linux machine, was near death. Definitely doing goofy things. Thus ensued a painful two weeks of reconfiguring Reliance, my new custom built workstation, transferring files, updating my development network, and all the good stuff you go through when you change PCs in midstream. A good eighty percent of my time was spent in man-page hell. I still haven’t figured out how to get my Infrant ReadyNAS network attached storage device to talk with Reliance. So I’m still without automated back-up. And, I must say, the Netgear gurus have been no help at all. Lord I hate computers some times.

So now we’re into the season of my son’s wedding, numerous family graduations, most requiring stressful travel, yada yada.

But the big news is this. Just as things settled down on the family events front my writing muse kicked me into an intense sprint to finish the first draft of my political thriller. Working title: Carmichael. But I’m seriously thinking about calling it God’s Wrath if somebody hasn’t already jumped on it. Waiting now for critical feedback. Then, after a rewrite/revision I’ll start the risky and arduous process of trying to bring it into print. If you’re a good critical reader and you like thrillers, drop me a line.

So now it’s time to start thinking deeply about Erlang again. I need to start working seriously toward building a site to help market my writing. My plan is to set up my own mini-on-line book store with a promotional blog and various other devices to bring in a few shekels for my words. Yes, I know I can use any number of polished open-source and/or proprietary programs to accomplish this. But I want to learn Erlang, dammit! And I always seem to go the long way around the barn. So, please, wish me luck.

The upside is this: I need to focus. Till now I’ve grazed promiscuously about the fields of Erlang. My plan now is to zero in on Nitrogen… see what I can do with it. I’ll need to invest serious programming time, which may mean somewhat less time posting to this blog, well, relative to my pace prior to early May.

But I’ll do my best to share what I learn along the way.

Erlang/OTP Callback Modules II

Hynek (Pichi) Vychodil kindly pointed me to Joe Armstrong’s thesis to help deepen my understanding of callback modules.

Starting on page 98, Joe talks about “abstracting out concurrency.”

Keeping track of many concurrent process is mentally challenging and error-prone, he says. For this reason he advocates a library of generic components, written by skilled Erlang programmers, and “plugins,” written by programmers competent in Erlang sequential programming. This component library, of course, has become OTP.

Says Joe, “The generic component should hide details of concurrency and mechanisms for fault-tolerance from the plugins. The plugins should be written using only sequential code with well-defined types.”

My quick reading did not turn up the phrase “callback module.” May be there. But I take it that “callback module” and “plugin” are synonymous.

Check out Joe’s thesis for yourself. Tons of invaluable background straight from the man himself.

One crucial point still clouds my aging brain: When you call a function in, say, a gen_server callback module and, say, it returns a tuple like {ok, yada yada}, who’s listening and expected to respond? I definitely need to think this one through before I get back to my walk-through of iserve.

Meanwhile, I’m packing up for Erlang University. Plan to spend three days learning what I can from Chris Anderson and Jan Lehnard about CouchDB.

The following two days, Thursday and Friday, promise many hours of brain food. I’m particularly looking forward to Rusty Klophaus’s Nitrogen presentation. If you haven’t been following Google Groups Nitrogen Web Framework for Erlang, drop in. Lively exchange of performance profiling data has been particularly interesting.

While rubbing shoulders with Erlang greats at Erlang University, I also hope to learn much more about Web Machine and Erlyweb.

Can’t promise, but maybe I’ll come back with a few pearls of wisdom. Maybe even a photo or two. I certainly plan to get back to my dissection of iserve.

So, be back sometime in early May just as soon as the jet lag wears off.

Erlang/OTP Callback Modules

Apologies for my April 19, 2009 post. For one thing, it’s much too dense. And worse, it’s wrong — at least seven of the last eight paragraphs.

Reading Erlang source really shouldn’t be rocket science. But I’m still struggling to follow the flow-of-control through Erlang applications.

One problem, for me, is this concept of “callback module.” I think I understand it, but the more I think about it the less confident I feel. I’ve tried to find a definition in Google, but failed. It seems to be one of those terms that everyone tosses around thinking that everyone else understands it.

But if I’m hazy, chances are there’s another Newbie or two out there scratching his/her head as well.

Problem for this Newbie is that the concept of “callback module” implies that something is going on behind the curtains. If I’m not all that clear about what’s going on back there, how can I be clear about what’s going on in the foreground?

So here’s my Newbie insight for the day. Caution: it may be wrong. If so, I beseech any passing Erlang wizard to set me straight.

Behaviours in Erlang/OTP are functional templates of oft-repeated code patterns, e.g., servers, finite-state machines, events, supervisors, and applications.

Callback modules fill in the slots in these templates to round out functionality for specific purposes. The “behaviour” is the generic, or abstract, part of the functionality. The “callback module” is the means through which the programmer tailors a behavior for specific application.

So how do we find out what’s going on behind the curtain? Erlang/OTP docs should certainly be our first stop:

Gen_Server Behaviour

“The client-server model is characterized by a central server and an arbitrary number of clients. The client-server model is generally used for resource management operations, where several different clients want to share a common resource. The server is responsible for managing this resource.”

Gen_Fsm Behaviour

“A finite state machine, FSM, can be described as a set of relations of the form:

“State(S) x Event(E) -> Actions(A), State(S’)

“These relations are interpreted as meaning:

“If we are in state S and the event E occurs, we should perform the actions A and make a transition to the state S’.”

Gen_Event Behaviour

“In OTP, an event manager is a named object to which events can be sent. An event could be, for example, an error, an alarm or some information that should be logged.”

Supervisor Behaviour

“A supervisor is responsible for starting, stopping and monitoring its child processes. The basic idea of a supervisor is that it should keep its child processes alive by restarting them when necessary.”

Applications

“When we have written code implementing some specific functionality, we might want to make the code into an application, that is a component that can be started and stopped as a unit, and which can be re-used in other systems as well.”

I’ll pick up on iserve again tomorrow; and try to view it from high overhead with these “behaviours” in mind.