| Patent application number | Description | Published |
|---|
| 20080320503 | URL Namespace to Support Multiple-Protocol Processing within Worker Processes - A server system in typical operation has a process manager, multiple listeners (each to receive requests for its protocols) and multiple worker processes that are each able to handle requests in multiple protocols. At server start-up, each listener connects with the process manager via a pipe published by the process manager. The listener then receives information via the process manager that includes information defining the application(s) for which that listener is to “listen” and associating application(s) to application pool(s). When the listener receives a request for such an application, the listener starts a queue for the associated application pool. The listener may use a hierarchical matching scheme to determine the associated application or application pool from the requested application. The process manager launches an appropriate worker process to handle requests in the listener's protocol. The worker process then makes a connection with the listener. | 12-25-2008 |
| 20090216782 | OBSERVING AND REPORTING CHANGES IN COMPLEX SOFTWARE DEPENDENCIES - An observation system includes mechanisms for efficiently tracking the state of source components, which include functions, arguments, or values, etc. In one implementation, an observing component requests that a source component processes a request. The observation system then identifies all possible components in a dependency chain for the request, and all such components that are configured for change notifications. A dependency registry stores a representation of each identified component that is configured for change notifications. Any time any component configured for change notifications changes, including indirectly related components, the observing component can be immediately notified of the change, without having to reprocess the entire set of component dependencies. | 08-27-2009 |
| 20090216793 | CONSISTENTLY SIGNALING STATE CHANGES - A signaling system of the present invention provides a synchronized approach to delivering, reporting, and/or otherwise processing status changes in a software dependency chain. In a first phase, the signaling system identifies all dependencies between software components, and further sets a binary indicator of each node in a first representation. After identifying any changes in a source node, the system (e.g., a value is updated), the system updates each binary indicator to a second setting. In a second phase, the system initiates all listeners in the dependency chain in an essentially progressive order from source node, to intermediate node, and end-node, etc. Once all listeners have had a chance to perform one or more processes based on the updated value, the system can discard the dependency graph, allowing a new dependency graph to be built for subsequent value changes. | 08-27-2009 |
| 20090222794 | UNIFIED EXPRESSION AND LOCATION FRAMEWORK - Allowing a continuation based runtime to resolve different types of location expressions, value expressions, and/or locations. This may be accomplished using a different class for each particular type. The location expression classes may each have a common method used for all of the location expression classes. The value expression classes may each have a common method, and the locations may also each have a common method. This allows the resolution of such location and value expressions to be treated in a unified fashion regardless of the type of location expression, or the type of value expression. Also, the location may be treated in a unified manner regardless of the type of location. | 09-03-2009 |
| 20090222827 | CONTINUATION BASED DECLARATIVE DEFINITION AND COMPOSITION - Declarative definition and composition of activities of a continuation based runtime. When formulating such a declarative activity of a continuation-based runtime, the activity may be formulated in accordance with a declarative activity schema and include a properties portion that declaratively defines one or more interface parameters of the declarative activity, and a body portion that declaratively defines an execution behavior of the declarative activity. The declarative activities may be hierarchically structured such that a parent declarative activity may use one or more child activities to define its behavior, where one or more of the child activities may also be defined declaratively. | 09-03-2009 |
| 20090300648 | Continuation-Based Runtime Callback Invocation - Activity callbacks in a continuation-based runtime. At framework-definition time, a framework activity is authored. The framework activity may have an environmental logic portion the processes input or output parameters whose values will be supplied to and/or received from an activity callback. The framework activity also includes a callback invocation portion that, during execution time, will actually provide parameter value(s) to and/or receive parameter value(s) from the activity callback. The framework activity serves as a framework that operates with any activity callback that has one or more characteristics. Such activity callbacks may not even be defined at framework-definition time. Instead, the framework activity may be used multiple times in the same applications, or in different applications to thereby provide core framework functionality, while allowing application developers to plug in activity callbacks that meet the custom needs of the application. | 12-03-2009 |
| 20100070983 | INTEGRATION OF RUNTIME ENVIRONMENTS - The integration of two runtimes. The integration may be accomplished via the sharing of all or a portion of the environments of each of the runtimes with each other. For instance, as one runtime executes a particular application, control may be passed at an appropriate point to the second runtime. The second runtime may pass control back to the first runtime at an appropriate time. This passing of control between runtimes may happen perhaps a number of times during the execution of the application. The applications might be expressed entirely declaratively in a manner that integrates both runtimes as the application executes. Thus, the application may take advantage of the strengths of each runtime at the appropriate time. | 03-18-2010 |
| 20100153930 | CUSTOMIZABLE DYNAMIC LANGUAGE EXPRESSION INTERPRETER - Embodiments described herein are directed to allowing a user to extend the functionality of a software code interpretation system. In one embodiment, a computer system receives user-defined conversion rules from a user for converting dynamic language code to continuation-based abstract memory representations. The computer system identifies portions of software code that are to be converted from dynamic language abstract memory representations into continuation-based abstract memory representations, where the identified code portions include undefined, extensible input primitives. The computer system also generates a dynamic, extensible set of output primitives interpretable by a continuation-based code interpretation system using the received conversion rules and converts the identified code portions including the undefined, extensible input primitives from dynamic language abstract memory representations into continuation-based abstract memory representations using the generated set of output primitives. | 06-17-2010 |
| 20100169862 | INTERFACE INFRASTRUCTURE FOR A CONTINUATION BASED RUNTIME - Namespace for continuation-based runtime. Some embodiments described herein are directed to a framework using continuation based runtime namespaces that pertain to an infrastructure for enabling the creation of a wide variety of continuation-based programs that perform a wide-array of tasks. The infrastructure provides a foundation for building continuation-based, declarative applications of various scale and complexity. In some embodiments, the associated application programming interfaces (APIs) are factored into a hierarchy of namespaces in a manner that balances utility, usability, extensibility, and versionability. | 07-01-2010 |
| 20110131191 | OBSERVING AND REPORTING CHANGES IN COMPLEX SOFTWARE DEPENDENCIES - An observation system includes mechanisms for efficiently tracking the state of source components, which include functions, arguments, or values, etc. In one implementation, an observing component requests that a source component processes a request. The observation system then identifies all possible components in a dependency chain for the request, and all such components that are configured for change notifications. A dependency registry stores a representation of each identified component that is configured for change notifications. Any time any component configured for change notifications changes, including indirectly related components, the observing component can be immediately notified of the change, without having to reprocess the entire set of component dependencies. | 06-02-2011 |
