Persistent Programming

From PEL Wiki

This is a list of paper about persistent programming:

Contents 1 An Approach to persistent programming (Atkinson et. al., 1983) 2 On the Unification of Persistent Programming and the World Wide-Web (Conner et. Al.) 3 Orthogonally Persistent Object Systems (Atkinson et. al., 1995) Overview Paper 4 Notes

An Approach to persistent programming (Atkinson et. al., 1983)

• Created a programming language to include persistence on typing.
  • 30% of code is concerned with transferring data to files or DBMS (from IBM Report).
  • Uses a database to achieve persistence, much like J2EE

On the Unification of Persistent Programming and the World Wide-Web (Conner et. Al.)

• This paper suggest that web applications will run into the same problem that persistent Programming is meant to solve.
  • Suggests that persistent programming solutions can apply to the web.
  • Comes up with a way to send typed objects over the web.

Orthogonally Persistent Object Systems (Atkinson et. al., 1995) Overview Paper

• Defines Persistent Application Systems (PAS)
  • Are long lived, concurrently accessed, large bodies of data and programs.
  • Examples include CAD systems, software engineering environments, patient-care support systems in hospitals.
• Presents an overview of current research in persistent application systems.
  • Need persistence to share data between process/applications.
  • Defines three principles which persistent systems must meet.
    • Persistence Independence - programs look the same whether they manipulate short-term or long-term data.
    • Data Type Orthogonality--data objects are handled the same, independent of type or length of persistence.
    • Persistence Identification--Use some method other than declaration to identify the persistence of objects (i.e. automatic garbage collection).

Notes

• The goal of Persistent environments is to completely eliminate data translation, storage, and sharing from the application programmers.

• Definitions
  • Persistence - Objects/Data lives longer than the process that created it.
  • orthogonal - The aim of an orthogonal design is to guarantee that operations within one of its components neither create nor propagate side-effects to other component (from Wikipedia).
  • Orthogonal Persistence - Objects are treated the same regardless of their persistent type.

• Reasons for Persistent Programming (Orthogonal Persistence)
  • Remove the translation to file system burden from the programmer (30% of code).
  • Allow different programs to share data.
  • Provide protection standards

• If persistent system requirements are defined, than why hasn't anyone designed a system that has all the requirements?
  • It seems like persistent programming is trying to be a smoking gun that solves all of the problems programmers have when dealing with data storage and sharing. However this may seem impossible because each application requires unique solutions. Are they continually changing the requirements because new different applications require different data facilities? Or are the requirements set, but they are just having difficulty in creating systems that support the requirements? Is it possible to describe all the data needs of every application?

• Maybe I should look more into how persistent memory will change desktop applications.