#lang scribble/manual @require[racket/include] @include{prelude.inc} @title{Concepts} In this paper, we present a novel "marketplace" approach to functional systems programming, generalizing Felleisen et al.'s "Worlds and Universes" approach to functional I/O [ICFP 2009]. We integrate ideas from both distributed systems and virtualized operating system designs to obtain a novel architecture of nested virtual machines. Each nested layer is equipped with its own publish/subscribe network that also propagates information about the (dis)appearance of services. Our paper presents several case studies, including a recursive DNS resolver that has served our lab's DNS traffic for the past nine months. Our goal is to reconcile this tension, starting from the "Worlds and Universes" approach to functional I/O and generalizing to functional systems programming. We augment its inherent support for concurrency with publish/subscribe (pub/sub) messaging, a notion of presence, and nestable virtual machines (VMs). The result suggests a @emph{ marketplace} metaphor, where communicating programs exist in a noisy, crowded, even chaotic context, rather than in a quiet place systematically going through their inboxes. @section{What is a process, what are event handlers?} @deftech[#:key "process"]{Processes} are ... @deftech{Process State} is ... @deftech{Events} ... @deftech{Actions} ... @section{What is a VM?} @deftech[#:key "vm"]{Virtual Machines (VMs)} are ... @section{Endpoints: Subscription and Advertisement} The Marketplace operating system's inter-process communication facility is structured around @deftech[#:key "pub/sub"]{publish/subscribe (pub/sub)} messaging.@note{For a survey of pub/sub messaging, see @hyperlink["http://www.cs.ru.nl/~pieter/oss/manyfaces.pdf"]{"The Many Faces of Publish/Subscribe"}, ACM Computing Surveys, Vol. 35, No. 2, June 2003, pp. 114–131. There's also plenty out there on the Internet; a good starting point is to google for @hyperlink["https://www.google.com/search?q=pub/sub message-oriented middleware"]{pub/sub message-oriented middleware}.} @deftech{Endpoints} are ... A @deftech{role} describes the role some process is playing in a conversation. Concretely, roles are represented by @racket[Role] structures. A role can be used by the currently-running process to describe some role it wishes to play, or can be carried in some @racket[EndpointEvent] to describe the role some @emph{peer} process is playing in a conversation. Roles have three parts: @itemlist[ @item{An @deftech{orientation} (type @racket[Orientation]) describes whether this role is concerned primarily with @emph{producing} or @emph{consuming} messages.} @item{A @deftech{topic} is a @deftech{pattern} over messages. Topics perform double duty: they both scope conversations and filter incoming messages. More on topics below.} @item{An @deftech{interest-type} (type @racket[InterestType]) determines whether the endpoint playing the given role is genuinely a participant in matching conversations or is simply observing the real participants. More on interest-types below.} ] @deftech{Messages} are ... @subsection{Topics} As mentioned above, topics ... @subsection{Interest Types} ... @section{Presence} @section{Nesting, relaying, and levels of discourse}