October is organized like the Web. Instead of Web pages there are top-level definitions. Top-level definitions are stored in a distributed repository implemented by October servers that are analogous to Web servers. They are viewed and manipulated by October browsers that are analogous to Web browsers. October servers and browsers communicate via the October protocol which plays the role of HTTP and allows different server and browser implementations to interoperate. The October protocol is designed from the start with support for searching, caching, mirroring, and load balancing. These play the role of search engines, proxy servers, and Web caches. Search is currently based on string matching, though future plans call for type-based search supported by local and global type inference built into the October protocol and implemented by the October servers. Top-level definitions are stored as abstract syntax trees (ASTs) which play the role of HTML. Instead of URLs there are version locators. Top-level definitions are hyperlinked via embedded version locators. When building an executable, the browser crawls the repository to fetch all top-level definitions referenced directly or indirectly by the top-level definition being built.
October is designed to be programming-language and programmer-preference neutral. It is neither a new programming language nor a new compiler. Rather, it supports existing programming languages and compilers. Just as the Web supports different document styles via DTDs, October supports different programming languages and programmer preferences via programming language definitions (PLDs). A novel aspect of PLDs is that they separate the definition of the abstract syntax for a given language from the mapping between abstract and concrete syntax. This allows users to configure their browsers to dynamically render the code they view in a different concrete syntax according to their personal preference. PLDs are currently written to support Scheme, C, and Java.
The overall goal of October is to boost world-wide programmer productivity by encouraging an unprecedented degree of source-code sharing, shifting the prevalent mode of programming from implementation to augmentation. In this talk, I will describe how October is designed to support this goal, discuss how this goal motivates and influences the creation of a new infrastructure, present some of the technical problems and design tradeoffs addressed so far while creating this infrastructure, and give a live demo of the prototype implementation of October.
The traditional model of the Internet is ``end-to-end'' -- two endpoints talk to each other directly, with nothing lying between them except routers that provide shortest-path packet forwarding. This model does not scale, so increasingly it is being violated by the placement of application-level intermediaries between endpoints. Some intermediaries are motivated by security (NAT, VPN), some by latency (web caches and load balancers), some by the multiplicity of link layers types (protocol converters), some by the multiplicity of endpoint devices (transcoders), and some by the consequences of size. An intermediary snoops on end-to-end conversations, typically TCP connections, understands part of the payload, and operates on the connection in significant ways.
Population of the Internet by a wide and growing variety of intermediaries gives rise to a ``Discrete Internet'' because a single application-to-application conversation is implemented as a sequence of hops not only at the IP routing level, but also among intermediaries at the transport and/or application levels. Implementing the Discrete Internet on top of the existing TCP/IP infrastructure is problematic. In particular, the TCP/IP model has nothing between the transport and application layers. Therefore, the transport protocol bears the burden of verifying delivery to the endpoint.
In this talk I will explain the ill consequences of using the same protocol for delivery verification as well as other services such as error recovery, ordering, congestion control, etc. I will then outline a proposed new ``connection layer'' lying between the application and transport layers. The connection layer explicitly recognizes the existence of a Discrete Internet, allowing creation and management of several transport connections that together form a single connection between two application endpoints, providing many advantages.
Encapsulation mechanisms, such as modules and classes, are intended to ensure that clients are not dependent on internal data representations used by services. But sharing of pointers often violates encapsulation. We give a notion of confinement that is sufficient to prove representation-independence for a substantial fragment of Java using a straightforward denotational semantics, and discuss practical issues for confinement disciplines.
The Statecharts approach for visually modeling behavior has a long history. With its adoption by the OMG as part of the Unified Modeling Language standard, it has gained widespread recognition. In this talk we discuss why the semantics of UML Statecharts, while adequate for design, is inappropriate for implementation. To address the issues raised, we propose a new language, ECLIPSEcharts, that incorporates modifications and extensions to UML Statecharts, and we compare it with existing languages. We also draw motivating examples from ECLIPSE, an IP-based framework for multimedia communication services which uses our implementation of ECLIPSEcharts on a daily basis for design and implementation.
Adriana Compagnoni / abc@cs.stevens-tech.edu