16 research outputs found
A Generic Storage API
We present a generic API suitable for provision of highly generic storage
facilities that can be tailored to produce various individually customised
storage infrastructures. The paper identifies a candidate set of minimal
storage system building blocks, which are sufficiently simple to avoid
encapsulating policy where it cannot be customised by applications, and
composable to build highly flexible storage architectures. Four main generic
components are defined: the store, the namer, the caster and the interpreter.
It is hypothesised that these are sufficiently general that they could act as
building blocks for any information storage and retrieval system. The essential
characteristics of each are defined by an interface, which may be implemented
by multiple implementing classes.Comment: Submitted to ACSC 200
Report on the XBase Project
This project addressed the conceptual fundamentals of data storage,
investigating techniques for provision of highly generic storage facilities
that can be tailored to produce various individually customised storage
infrastructures, compliant to the needs of particular applications. This
requires the separation of mechanism and policy wherever possible. Aspirations
include: actors, whether users or individual processes, should be able to bind
to, update and manipulate data and programs transparently with respect to their
respective locations; programs should be expressed independently of the storage
and network technology involved in their execution; storage facilities should
be structure-neutral so that actors can impose multiple interpretations over
information, simultaneously and safely; information should not be discarded so
that arbitrary historical views are supported; raw stored information should be
open to all; where security restrictions on its use are required this should be
achieved using cryptographic techniques. The key advances of the research were:
1) the identification of a candidate set of minimal storage system building
blocks, which are sufficiently simple to avoid encapsulating policy where it
cannot be customised by applications, and composable to build highly flexible
storage architectures 2) insight into the nature of append-only storage
components, and the issues arising from their application to common storage
use-cases
Working Document on Gloss Ontology
This document describes the Gloss Ontology. The ontology and associated class
model are organised into several packages. Section 2 describes each package in
detail, while Section 3 contains a summary of the whole ontology
Second Set of Spaces
This document describes the Gloss infrastructure supporting implementation of
location-aware services. The document is in two parts. The first part describes
software architecture for the smart space. As described in D8, a local
architecture provides a framework for constructing Gloss applications, termed
assemblies, that run on individual physical nodes, whereas a global
architecture defines an overlay network for linking individual assemblies. The
second part outlines the hardware installation for local sensing. This
describes the first phase of the installation in Strathclyde University
Reflection and reification in process system evolution : experience and opportunity
Process systems aim to support many people involved in many processes over a long period of time. They provide facilities for storing and manipulating processes in both the representation and enactment domains. This paper argues that process systems should support ongoing transformations between these domains, at any level of granularity. The notion of creating a enactment model instance from a representation is merely one restricted transformation. Especially when process evolution is considered the case for thinking in terms of model instances is weak. This argument is supported by our experience of the ProcessWeb process system facilities for developing and evolving process models. The idea of hyper-code, which supports very general transformations between representation and enactment domains, is described. This offers the prospect of further improvements in this area.Postprin
Report on the XBase project
This project addressed the conceptual fundamentals of data storage, investigating techniques for provision of highly generic storage facilities that can be tailored to produce various individually customised storage infrastructures, compliant to the needs of particular applications. This requires the separation of mechanism and policy wherever possible. Aspirations include: actors, whether users or individual processes, should be able to bind to, update and manipulate data and programs transparently with respect to their respective locations; programs should be expressed independently of the storage and network technology involved in their execution; storage facilities should be structure-neutral so that actors can impose multiple interpretations over information, simultaneously and safely; information should not be discarded so that arbitrary historical views are supported; raw stored information should be open to all; where security restrictions on its use are required this should be achieved using cryptographic techniques. The key advances of the research were:1) the identification of a candidate set of minimal storage system building blocks, which are sufficiently simple to avoid encapsulating policy where it cannot be customised by applications, and composable to build highly flexible storage architectures 2) insight into the nature of append-only storage components, and the issues arising from their application to common storage use-cases
A generic storage API
We present a generic API suitable for provision of highly generic storage facilities that can be tailored to produce various individually customised storage infrastructures. The paper identifies a candidate set of minimal storage system building blocks, which are sufficiently simple to avoid encapsulating policy where it cannot be customised by applications, and composable to build highly flexible storage architectures. Four main generic components are defined: the store, the namer, the caster and the interpreter. It is hypothesised that these are sufficiently general that they could act as building blocks for any information storage and retrieval system. The essential characteristics of each are defined by an interface, which may be implemented by multiple implementing classes
Current directions in hyper-programming
The traditional representation of a program is as a linear sequence of text. At some stage in the execution sequence the source text is checked for type correctness and its translated form is linked to values in the environment. When this is performed early in the execution process, confidence in the correctness of the program is raised. During program execution, tools such as debuggers are used to inspect the running state of programs. Relating this state to the linear text is often problematical. We have developed a technique, hyperprogramming, that allows the representations of source programs to include direct links (hyper-links) to values, including code, that already exist in the environment. Hyperprogramming achieves our two objectives of being able to link earlier than before, at program composition time, and to represent sharing and thus closure and through this the run-time state of a program. This paper reviews our work on hyper-programming and proposes some current research areas.Postprin