Let’s catch up

There are some things we need to discuss. Sit down for a moment, will ya?

On architecture

Take, for example, the following carefully rendered graph:

Don’t take its elegant ASCII too seriously; it’s a 5 second draft. But between its pipes and backslashes, there are some questions to be pondered.

On ?? process

The ?? process sits on the same server as the web application(s), consuming relevant dtrace events and packaging them up to be transfered over the wire to another application that collects said events. This separation is done so as to be able to monitor several servers at a time.

• What type of process does ?? need to be?
• Is something as simple as netcat enough?
• Is Orchestra (http://github.com/brynary/orchestra/tree/master) a great match?
• Should Bonjour be implemented on the ?? process to minimize configuration?
• Is a single process enough, or should several processes be instantiated?

On view

The View server receives a notification every time a dtrace probe fires back on the web applications. Its job is to act as the interface between the probes and a user wanting to visualize them. It’ll be packaged as a rack/sinatra middleware application for maximum portability and buzzword compliance.

• How should the notifications/probe events data be saved?
• Should all probe events be saved?
• Is a sampling enough to get accurate data?

On protocol

All the visualization code runs on the browser, courtesy of Processing.js. So… what about the data that gets visualized? We want as close to real-time processing as we can get, right?

• Long polling?
• JSON-P?
• How much processing of the data should take place on the browser?
• How much should be taken care of back on the server?

These questions are meant to be rhetorical right now, as this week is still responsible for implementing some visualizations. Eventually the questions will have to be dealt with, so I’ll be keeping them in the back of my mind.