Análisis de casos documentados

By reusing code, users can be assured of the quality of the code and accuracy of its results. The FOM does not offer any inherent means to kitemark code, nor does it set minimum requirements for submitted code. This means that erroneous code can be added to the system.

There are two solutions offered for this problem. One is that users will quickly identify faulty code and be able to remove the methods. This relies on the user com- munity helping to continuously improve the code quality, but does not compensate for malicious code.

The second option only permits the owner of a method to execute it until the method has become mature enough to get released to the community. Establishing when a method is mature and promoting users to publish methods is foreseen as difficult and does not encourage the community spirit of the FOM. For this reason the FOM does not have the ability to restrict methods to particular users or user groups.

all the code accessible to the user community is free from malicious code.

3.5

Discussion

The ability of the FOM to support many programming languages adds complexity to the project. Wrapping or integrating different programming languages can often be impossible or prone to errors. It is for this reason that this feature will never be fully implemented, to supportanyprogramming language. To ensure that the FOM is non-intrusive and of benefit to users we aim to support as many of the key programming languages as possible. It is important that users are free to write FOM methods their programming language of preference. It is for this reason that the language independence feature remains in the FOM despite being impossible to fully implement.

The issue of code quality will always be in dispute as it is not possible to check all the code submitted. This feature remains in the FOM specification as the aim is to provide some assurances, i) user’s code cannot compromise the host system, ii) user’s code cannot corrupt the data stored in the FOM. As most of the security issues rely on the implementation, the aim is to provide as many assurances as possible and highlight the limitations.

The FOM data security comes from the underlying OS, providing a user has permissions to change data the FOM permits the operation.

The FOM does not control the names that users provide for methods and classes, hence naming clashes are expected. This could be overcome by using a namespace similar to that used in Extensible Markup Language (XML) (W3C, 1999) or provid- ing an internal FOM name. The end result has to ensure that the FOM is capable of dealing with methods of the same name from different users.

3.6

Summary

This chapter proposes a concept, called FOM, where files are treated as objects, ex- posing users’ code as methods on these file objects. The aim is to enhance the user’s data management experience without drastic changes to the user’s existing work- flow. We discuss how the proposed method can integrate with existing workflow.

The key objectives of the FOM are to preserve the user’s data format, and the ability to reuse existing code such that the FOM is non-intrusive to the user.

The FOM provides operations which enable users to deposit and retrieve data into the repository. Once the data is stored in the FOM, users have the ability to submit and execute code on the data.

The FOM objectives and operations are discussed along with an implementa- tion independent description of the FOM. The FOM provides a series of features

which are then described. These features are used in subsequent chapters to dis- cuss different implementations of the FOM.

Chapter 4

File object method prototype

4.1

Introduction

In this chapter we present a prototype implementation, called the File Object Data- base (FODB) based on the File Object Method (FOM) concept discussed in chapter 3. The File Object Database (FODB) prototype demonstrates some of the key FOM features and provides a discussion into possible future implementations.

We provide insight into a Python implementation and demonstrate the FOM concepts using a simple example. In this example we have chosen to store the user’s data in a text file to show clearly how the FOM features operate on the data. The example shows how users can discover methods related to a file, and explains how user code can be submitted and executed using the FODB.

This prototype aims to be a proof of concept for the FOM, used to identify lim- itations and test the feasibility of the model. From the findings in this chapter we go on to produce production quality improved implementations, as discussed in chapters 5 and 7.

We demonstrate the capabilities of the FODB using a simple example which shows both the FODB implementation and its limitations.