User:Scott Parlane/DesignStudy

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
= Project (Out of Band Synchronisation) =
+
= Project (Programming Language Parser) =
 
== Description ==
 
== Description ==
Provide a solution for performing offsite back ups, where directly transferring the data is impossible or incredibly expensive, however regular transport between locations is avaliable and at least 1 operation computer is transferred between sites.
+
My project is a parser for LTF (Logic, Types, Flow). The scope is limited to the parser only due to amount of work associated with writing a full compiler or interpreter, and the parser will sufficiently show/prove the design in implementation.
 +
I have a previous parser (written in C++) that can parse a language with similar logic/type declarations. However this project is mostly new, some parsing, OO, and language concepts are shared from the previous project.
  
 
=== Goals/Requirements ===
 
=== Goals/Requirements ===
* Synchronise data using out of band data transfer.
+
* Parse and create an AST (Abstract Syntax Tree) of the LTF.
* Support extremely slow, high capacity links. (80+GiB with 1 week latency)
+
== About LTF ==
* Support multiple transfer agents.
+
LTF is designed for writing code similar to the way the shell works, except with much more flexibility, as data can be pushed to any of the objects, not just in a forwards directions.
=== Constraints ===
+
Code is written in 3 seperate parts:
* WORM data assumed (allowing for rename/move/etc)
+
* Type information is the meta data describing each of the types in the system. (Like a header file)
== Initial Design ==
+
* Logic is the code that implements the functionality of the types. (like normal code files)
* Make use of [http://www.4underscore.net/] infrastructure (espically networking code).
+
* Flow creates objects and connects them together (similar to a main function)
* Use the code generator git://git.scottnz.com/generator.git/ to generate OO code from a design spec.
+
Things to note:
* Split system into 3 parts: metadata store, data servers, and transfer agents.
+
* LTF supports single inherientance.
Warning: Notation used below is similar, but not the same as, the notation used by generator, this is intentional, until more graphical representation can be created.
+
* LTF supports interfaces, on a per function basis.
=== MetaData Store ===
+
* LTF is a push system, data always moves from in to out.
Tracks the entire tree of each data storage server and
+
* input functions do not return a value, the correct solution is to input an error to the caller.
* Location (Pointer(Char):Name, ArrayObjectPaired(Server,Directory):Servers,ArrayObject(Transporter):Agents)
+
* Logic is pre-order, and bracketing is non-optional.
* Directory (ArrayObject(Directory):SubDirs, ArraryObject(File):Contents, Pointer(Char):Name)
+
 
* File (Pointer(char):Name, Pointer(char):md5, Pointer(char):sha1)
+
== Design ==
* Server (Pointer(Char):Name, ArrayObject(Location):Locations)
+
Root types:
* Transporter(Pointer(Char):UUID, ArrayObject(File):Carrying)
+
* Module (all of [name].{type,logic})
=== Data Store ===
+
* Program (a program, described by a flow)
Provides long term storage for all of the tracked files
+
* AST (some item in the AST, an option of some sort)
* Location (Pointer(Char):Name, Array(Directory):Root, Pointer(Char):Path)
+
* Connection (some item of flow)
* Directory (ArrayObject(Directory):SubDirs, ArraryObject(File):Contents, Pointer(Char):Name)
+
 
* File (Pointer(char):Name, Pointer(char):md5, Pointer(char):sha1)
+
Types inherieting from AST:
=== Transporter ===
+
* CodeAST
Provides a temporary storage area for transporting data between data stores
+
* AccessorAST
* Path (Pointer(char):Name, ArrayObject(File):Contents)
+
* File (Pointer(char):Name, Pointer(char):md5, Pointer(char):sha1)
+

Revision as of 10:49, 7 August 2010

Contents

Project (Programming Language Parser)

Description

My project is a parser for LTF (Logic, Types, Flow). The scope is limited to the parser only due to amount of work associated with writing a full compiler or interpreter, and the parser will sufficiently show/prove the design in implementation. I have a previous parser (written in C++) that can parse a language with similar logic/type declarations. However this project is mostly new, some parsing, OO, and language concepts are shared from the previous project.

Goals/Requirements

  • Parse and create an AST (Abstract Syntax Tree) of the LTF.

About LTF

LTF is designed for writing code similar to the way the shell works, except with much more flexibility, as data can be pushed to any of the objects, not just in a forwards directions. Code is written in 3 seperate parts:

  • Type information is the meta data describing each of the types in the system. (Like a header file)
  • Logic is the code that implements the functionality of the types. (like normal code files)
  • Flow creates objects and connects them together (similar to a main function)

Things to note:

  • LTF supports single inherientance.
  • LTF supports interfaces, on a per function basis.
  • LTF is a push system, data always moves from in to out.
  • input functions do not return a value, the correct solution is to input an error to the caller.
  • Logic is pre-order, and bracketing is non-optional.

Design

Root types:

  • Module (all of [name].{type,logic})
  • Program (a program, described by a flow)
  • AST (some item in the AST, an option of some sort)
  • Connection (some item of flow)

Types inherieting from AST:

  • CodeAST
  • AccessorAST
Personal tools