People have expressed interest in these projects:

Web Auction
web interfaces for buyer and seller are treated as sites. Orc's role is to receive bids, manage notifications, generally run the auction. (Jyotsna , Divya )1-2 people. See Greg Plaxton's work.
  • Why this is important: auctions are complicated orchestrations between multiple parties. This will make a compelling demo.
  • Where to get started: Greg Plaxton's group is developing a Java library which implements an interesting auction algorithm; contact him for more information.
  • What we expect: an interactive demo involving multiple buyers and sellers.
Music library
develop library of music primitives for composing MIDI scores in Orc. See ChucK. 1-2 people (Junlin Yi, Ke Xiao).
  • Why this is important: ChucK demonstrates the power of manipulating sound through concurrent programming. Orc should be able to do everything ChucK can.
  • Where to get started: read the ChucK introduction paper and make sure you understand how ChucK's "shreds" and timers are related to Orc threads and logical time. Write some sites which allow you to generate MIDI commands from an Orc program and use these to write a "Happy Birthday" song. Then expand on this with more interesting demos; perhaps a fugue where different processes running at different rates produce interesting musical effects. Use ChucK for inspiration.
  • What we expect: a library of sites for generating music or sounds in Orc, and a demo of some applications using these sites.
  • Sequencer may be useful for anyone working on this project.
Mobile applications
for Google Android platform. (Suudhan Rangarajan) 1-2 people.
  • Why this is important: a mobile platform should allow interesting orchestration applications.
  • Where to get started: start by making a "Hello World" Android application. Then port the Orc compiler and interpreter to Android, so that you can run simple programs in that environment (this should require only minimal changes). Then focus on developing interesting sites and creative demos which take advantage of Android's features.
  • What we expect: an interesting demo of an Orc program running in the Android emulator or on your phone.
Orc in Javascript
implement a Javascript interpreter for OIL. 2 people.
  • Why this is important: something like Google Web Toolkit for Orc will allow in-browser mashups which are more interactive than our current demos, which run entirely on the server.
  • Where to get started: review the existing implementation. Essentially you will be translating the runtime portion (in orc.runtime) from Java to Javascript.
  • What we expect: a demo of an Orc program controlling an in-browser mashup. At a minimum, you will need to:
    • Call the Compiler web service to turn program text into an AST.
    • Implement the Javascript runtime which translates the AST into a DAG.
    • Implement the standard library sites in Javascript.
    • Implement some additional sites which allow interesting interaction with programs in the browser.
Toy OS
task scheduling, memory, and communication primitives; no device drivers or file system. See Mike Dahlin's OS API. 2-3 people.
  • Why this is important: an OS is a complex orchestration. Implementing an OS in Orc should give insight into its concurrent structure and hopefully solve certain problems very elegantly.
  • Where to get started: Mike Dahlin's OS class project walks you through creating a basic operating system. Your goal will be to implement some non-trivial portion of this in Orc, on simulated hardware. You may also look at House, the Haskell Operating System, for ideas on developing an OS in a high-level FPL.
  • What we expect: A demo of your OS handling some trivial processes. A discussion of your design, and how traditional OS features are expressed as orchestrations.
Event-based programming
Examples: state machines (car light), video games (tetris), GUIs.
  • Why this is important: event-based programming is a paradigm for interactive applications. Orc should be able to express such applications elegantly.
  • Where to get started: Read up on the event-driven paradigm and choose one or two applications which are suited to this paradigm. Then develop these applications in Orc.
  • What we expect: demos of event-based programs and a discussion of how event-based programming is expressed in Orc.
Animation library
develop library of animation primitives for creating animations in Orc. See Processing, Turtle graphics, Fran. 1 person.
  • Why this is important: to visualize orchestrations and create compelling graphical demos and applications
  • Where to get started: study existing animation libraries/frameworks like Processing and design a library of sites for Orc based on these. Focus on creating animation primitives which can be composed temporally (via the Orc combinators) and spatially (via function application).
  • What we expect: several interesting graphical demos and a discussion of animation library design.
Algorithmic animation
develop techniques/API for superposing animation on algorithms of a certain class (i.e. graph algorithms, array algorithms, message-passing systems). May want to generate animations from a program trace. May depend on "animation library". 1 person.
  • Why this is important: to visualize orchestrations and create compelling graphical demos and applications
  • Where to get started: a previous class project demonstrates some basic algorithm animation which you can study for inspiration. You will need to decide:
    • what class of algorithms / data structures you want to animate
    • whether to do online animation (by augmenting the program to animate) or offline (by analyzing a program trace)
  • What we expect: several interesting graphical demos and a discussion of the library design.
Provisioning
general problem is to schedule resources with soft/flexible requirements. Delegate actual scheduling to a site, Orc's role is to manage waiting lists, cancellations, notifications, and passing requests to the scheduler. Greg Lavender to provide examples. 1-2 people.
  • Why this is important: SUN is interested in how Orc can help them manage scientific computing clusters.
  • Where to get started: You can see this project as reimplementing some subset of OSCAR in Orc.
  • What we expect: a discussion of the provisioning problem in general, how it can be treated as an orchestration, and a small demo/simulation of your solution.
Network simulation library
develop library of sites for network simulation. Sites implement different types of servers, transports, and protocols. 1 person. See MITRE network design patterns.
  • Why this is important: network protocol simulation is an application domain for Orc.
  • Where to get started: assuming you have some knowledge of network protocols, choose one or two protocols which would be interesting to simulate and identify the sites that would be necessary to build a simulated network. You can choose the OSI layer which is most interesting to you, but something around the IP layer is probably appropriate, i.e. sites will include: routers, ethernet links, switches, packets, etc.
  • What we expect: a demo of your library on some basic network simulation problems, and a discussion of the issues involved.

The following projects are also available.

ForensicOrcDebugger
finish implementation of forensic debugger. 2-3 people.
Bytecode compilation
prototype which compiles OIL to Java bytecode. 2-3 people.
Robot control
Orc for robot and multi/agent control. See Player/Stage platform. 1-2 people.
REPL
implement REPL for developing Orc programs interactively. 1-3 people.
Adaptive workflows
hot code swap: how do you migrate state between an old and new version of an orchestration?
Physical simulations
telephone network, automobile traffic, bank tellers, fast food restaurant. See Simulation using Orchestration.
Multi-processor Orc
enhance engine to use multiple processors, and do experiments to illustrate scalability. 1 person.
Distributed scheduler
(work-stealing) for automatically distributing an Orc program over multiple machines. (This problem is a superset of the multi-processor Orc problem.) 2 people.
Distributed Make
implement sites similar to Ant tasks. Dependencies are represented implicitly by variable dependencies. 1 person.
B2B applications
(BPEL). With rollback? 1-2 people.
Parallel ray tracer
self-explanatory
Type systems
Interfacing with other type systems (XML Schema, C, ...).
FFI
for sites implemented in C, Erlang, Ruby, or other language.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-5) was last changed on 12-Feb-2009 19:42 by Junlin Yi