ARCH Project Goals (Explained) ============================== [Contents] [Contents] [History] [Purpose] [Design] [Independent] [Abstract] [Simple] [Free Flow] [Free Life] [Free Form] [Implementation] [Unrestricted] [Compatible] [Commonality] [Interopability] [Standard System] [Universal] [Complete] [Mutable] [Open] [End] [History] 20000107 Created 20000123 Updated [Design] 20000202 updated [Implementation] updated [Standard system] [Purpose] This document is to provide further explation of the goals behind the ARCH system. It's approach will be less rigorous and more casual than the goals documentation. [Design] The design methodology to be introduced in the ARCH project should be an attempt to capture all types of operations that can be done on computers, in real life, and in fantastical worlds. This is truly the essence of where my concept of "Absraction Theory" comes from, the design aspect. While Abstract is only one goal of the system, that title is used with specific popular meaning. [Independent] Although there is no doubt that many of the ideas and concepts expressed in the ARCH system will be derived from other systems, it is not my intent to have this system simply a rehash of an existing one with a bit of new functionality. This system must be something new, something unique. The second part of the goal is that it must be complete, that is not an extension of some other system. I don't want this to be that which adds all the missing stuff to OOD. I don't want this to even rely on what people accept procedural programming to be. I want this to totally define everything that is anything in this system. [Abstract] This is a fairly simple goal that the design approach is not to be focused on the implementation details. In this sense the design process can be used for more than just computer systems, but the focus of this project is obviously on exactly those systems, with the implementation being only for a computer system. [Simple] No component being subdividable means that given a particular operation, it may not be composed of some lesser operations. This applies to operation visibility though, since this is only design, and not implementation, what actually happens is not relevant. No component can be eliminated means that each operation that is deemed fundamental must actually be fundamental. If the operation only supports a set of design that isn't actually needed, then it should not be there. This does not mean that if only a tiny fraction of the system will use it then it shouldn't be there, for it's quite possible that tiny fraction of the system provides a needed behaviour to satisfy the other goals. This really addresses those things that one would consider "handy", but not required. Not being mutable means that a principal can't be cleverly applied to achieve a goal it wasn't meant for. Principals have to be unique in their usage. All of these goals under the heading of Simple are here to make sure the system isn't abused, and doesn't neglect some potentially desired behaviour. This is a key goal that is the more difficult part of the system to achieve, as it is the limiting factor when trying to achieve the Free Flow / Life / Form goals. [Free Flow] Free Flow is the concept of the system that relates to actual execution paths (or series of instructions). There is no attempt here to mimic the way a computer operates, the intent is to provide for any possible scenario of execution. The basics of this concept are that execution has to be able to start, it has to be able to end, and a single path of execution must be able to occur across and entire system, (no matter how many computers it may span). To give a further idea of what might happen, here are several of the common examples of free flow, this list does not include everything, and does not constitute complete achievement of the goal: Non-Distinct - The functioning and appearing of a path of execution (from the user's point of view) must not vary from any other component in the system. It must adhere to all of the goals, and therefore will look like just another handle Contextual - A path of execution must be uniquely and constantly identifyable, that is, if a path of execution spawns many threads, processes, or computers, it must appear the same to the user Origin - Given a runnable handle execution must be able to start there Termination - Any origined path of execution must be able to complete in some fashion Asynchronous - A path of execution can at any point request a furthered state of execution in an asynchronous fashion and continue on it's own Recoverable - a physical failure in the path of execution must be recoverable without resulting in failure in another path of execution [Free Life] Free Life is the concept of the system that relates to the existance of implements. Implements are those things that actually represent sets of instructions and the data that goes along with them (you will note in this system it isn't possible for a user to determine the nature of an implement, code, or data). This concept is trying to imply that implements can be created and destroyed freely. It should also imply there would be a mechanism for storing these implements for later use, or migrating the implement from one path of execution to another. Creation - an implement needs to be able to be created at any point in any path of execution Destruction - an implement needs to be able to be destroyed at any point in any path of execution Metamorphisis - an implement must be able to change its nature, and a handle must be able to change its underlying implement Migration - the ownership of an implement must be able to travel from one path of execution to another. At an implementation level this means that an implement on one machine must be able to move to another machine, its operation continues as normal, but it no longer resides on the original machine, this is NOT a proxy system. Stasis - an implement needs to be able to be unloaded until further use is required, without the operations of the object being effected [Free Form] Free Form is the concept of the system that allows relationships to be established between various implements and other system functionality. This is the biggest divergence from any classical approach to design, as there is no restriction on the relationships that can occur, and there is no encouragement of any particular relationship. The idea is to use whatever form is best at the given time. As examples here are provided some of the relationships that can occur, this is by no means all of the relationships, and doesn't in any way determine the requirements of the system (other than all of these must be supported): NOTE: Relationships generally occur between implements at the interface level. Specialization - one implement maintains another as its base implementation, the first implement specializing, or further impelmenting, the interfaces of the base implement. The base implement may have operations that result in a call to the specialized implement. Proxy - one implement is acting as a gateway of sorts to another real implement, translation, buffering, and other such operations may occur Adapter - one implement is translating the requests on an interface to the format of requests on another interface Containment - an implement contains in it several handles Joint - combines the requests over several interfaces into requests along a fewew number of interfaces Branch - distributes requests from a few interfaces to requests over several more interfaces [Implementation] Implementation is the part of the system where things actually get done on a real computer. Note that up until this point there is no assumption about the nature of the system to be used for implemenation, or even that a computer is being used at all. The intent of the implemenation is to work on all computers with any operating system. The limit to this is that the system must be sufficiently modern enough to handle the requirements of the design -- a utopian system will not be sought, systems such as Win32 and Solaris are examples of systems it should work on. Primarily the problem the core implementation should seek to resolve is fundamental operation of a design: the connectivity between components, loading and unloading principals, the basic operations of free flow, form, and life. It does not seek to provide a standard operating environment, that is what the "Standard System" is for. [Unrestricted] Not being restricted means that the implementation shouldn't have the limitations of any particular programming language or operating system. As recalled the goal of the implementation is to match the design system. There is no attempt to make use of the system match the methodology primarily used by a particular programming language; that is, the C++ mapping will not necessarily be object oriented or use exception handling. [Compatible] Compatibility is for the purpose of allowing somebody to use whatever language they are most comfortable with, or with a language best suited for what they are trying to achieve. While it would be nice to try and map the system constructs to native ones in the language, it just may not be possible, but this should not preclude using the entire language feature set in conjunction with Arch. Compatibility with operating systems is to imply that none of the core functionality should be dependent on a particular operating system feature. This does not imply transparency, it may very well be the core of the system is implemented quite differently from machine to machine, it just implies that a core can exist. [Commonality] Commonality is akin to IDL files in CORBA. There is to be some intermediate representation of many of the design concepts that are not yet system/language dependent. This is to provide mainly a consistant technical documentation, and exchange mechanism for use. [Interopability] Interopability's goal is make one Arch work with another Arch, whether it is on the same machine, or a different machine. The goal has three levels to this Like Systems - a like system is one with the same core architectural parameters, basically the same core running somewhere else Unlike Core Parameters - This is the ability to talk to other Arch systems built with differeing core parameters, such as pointer size, structural packing / alignment, etc... Things that would normally render system incompatible. Unrelated Systems - This is the dream goal, it may not necessarily be 100% transparent but that is the goal. Basically put this allows Arch to work with systems like CORBA or DCOM. [Standard System] If the Implementation is where stuff actually gets put onto a real computer, then the Standard System is the part that actually does something. It should be pointed out that neither the Design nor Implementation mentions anything about operational primitives, such as synchronization, memory management, communications, loading, registrations, etc... All of these concepts are to be handled in the standard system. The first goal of the standard system, moreso a part of Design/ Implemenation is that it should be fully implemented on a correctly functioning core Arch implementation. No special extensions just for the Standard System should be available -- note the Mutable requirement. [Universal] Universality is probably the trickiest of the goals to achieve, it is the one that actually requires the most amount of design work to be done. The other goals are merely architectural practices, whereas this one is a genuine paradign of operations. The notion here is that nothing is ever duplicated needlessly, so any component that is similar to another one, should have the same functionalities of the other one. So, a window is a window is a window, if any of these windows can be printed, then they all can be. If one component allows reading binary data from it, then it must use the same interface as all other components that allow the reading of binary data. This is the basis of the abstraction theory in work, all things must share a fundamental root. [Complete] Completeness implies that any modern application can be developed fully in this standard system. The standard system approaches general use however, not specialized use, such as games. Indeed the first run at the standard system will probably not have a robust system for multimedia. A complete system means that if somebody develops solely for the Standard System their code can be reused on any operating system that supports Arch, WITHOUT ANY MODIFICATIONS TO THEIR SOURCE CODE. [Mutable] A part of the intent of mutable is to indicate a properly functioning core system. No component in the Standard System should use special purpose functions in the core system. The standard system has no more rights than any other designed component. This also means that any component in the standard system should be replaceable, that is independent of the remainder of the system. So while the Standard System has to be complete, it should not represent an indivisible unit. [Open] This may seem similar to Mutable, but it differs in that Mutable refered to the functionality as provided directly by the Standard System, Open refers to the ability to extend that basic functionality. In this Open system it should be easy to add new components, or extend existing components, without having to rework the Standard System. Every major section of the standard system has to be manageable by some entity that can control more than just the standard system. Indeed, the standard system will be implemented in layers, such that the first layer of the standard system will be fundamentals (like syncronization) and management/control components -- the remainder of the system will be built on top of that, ensuring openness. [Full Access] This is the point where ARCH's cross-platform, indepdent, abstract beauty simply falls apart. A realistic goal of this system is to develop real programs for real operating systems. Many of these programs may have special requirements beyond that of ARCH's framework. It is often useful to develop generally within a large framework and every so often directly access the computer system (the reason for the existance of DirectX). Full Access provides this mechanism. It implies that at any point where possible (and there will be hundreds where it is not possible), the real operating system handles and data structures should be retrievable for use directly. So if you have a Window, in Win32 somewhere you can get the HWND value if it exists. NOTE: In the abstract world these handles may not be consistant, nor may they even exist at times. On that last point, Full Access cares not about being compatible within Arch. If the underlying handles are of no value, too bad, it isn't a goal of this system to make sure they are. If using the underlying handle breaks Arch, too bad, it again isn't a goal of the system to allow dual interfaces. Use of full Access will require a great deal of care. [End] This is the end of the ARCH Project Goals (Explained) document.