Back | Home | Next

Serialization

ANNA  K5

@

Home
Glossary
Objectives
Formalism
Morphology
Physiology
Connectors
Serialization
Traits
Methods
Claims
Relations
Dictionary
Core UML
Ring1 Apps
Tiger Server
Features
History
ToDo
Authors
API
Images
ToDo
DNA Declarations
Physiology RO
Real Time RO
ANNA as an Eco System RO
HMM Generator
ERP

 

1           Abstract

1.1         USER and SERVER

  1. Server may have 0 or more Users
  2. Users are accessories to Servers
  3. User is a special proxy to one target Server
  4. Server allocates its Users
  5. User locates its Server through Handle

1.2         PROXY and TARGET

  1. Proxy is an object that impersonates one other.
  2. Proxy and Target are of the same type
  3. Proxy differs from Target in allocation.
  4. Proxy is accessory to a User
  5. Proxies to the same Target may coexist for a User.
  6. User allocates proxies to target objects belonging to Server
  7. Target tracks all its proxies.
  8. Proxies to the same Target and belonging to different Users may coexist.

1.3         Indirect proxies

  1. A proxy to another proxy to a Target has the type of the final Target.
  2. Indirect proxy points to a more direct proxy through Handle.
  3. An arborescence of Proxies leads to its root Target.

1.4         Locating

  1. Knowing a proxy, the corresponding target object on the Server can be located by first dereferencing the User, locating the user’s target to find the server, finally dereferencing the server to the proxy’s handle to the target object.
  2. Starting with a Target object, all proxies of the object may be tracked to any outer rim in the concentric circles of proxy levels.

1.5         Handle

  1. Handle is an abstract attribute of each Object
  2. The type and meaning of Handle is assigned by the Object’s Container. (See systems, nested objects, containment)
  3. Handle is a storage expression within a scope of one more persistent scope.
  4. Volatile objects lease the more persistent space and use only in accordance to the terms of use defined by the surrounding object.
  5. Object cannot directly dereference its Handle and must delegate the dereference to its Container. Container resolves the dereference on behalf of its contained object to a construct of the same volatility as the contained object that may now be used directly.
  6. Object delegates Container with a Handle to get back a usable typed construct.
  7. To resolve the dereference, the Container can recurse the process by delegating its container, and so forth.

1.6        

 

S’

 

O

U

P

U’

P’

S

Proxies to proxies to Servers

  1. A local proxy P is required to an object O contained in server S.
  2. A local user U is created to hold P and others like it. U is contained in S, at he same volatility level as O, thus setting P to be more volatile than its target O.
  3. Another more remote proxy P’ can now be taken to P with the creation of another user U’ contained in remote server S’ which is peer with S.
  4. P’ ---> P ---> O is the path of locating target O starting from S’.
  5. U and U’ are considered identical.
  6. U’ handles U and U handles U’ in cross-over.
  7. The crossed-over U-U’ pair is called a PORTAL.
  8. The characteristics of this construct is that U belongs to S and U’ belongs to S’ and create a window for exchanging substance between adjacent system S and S’.

1.7         PORTAL and GATE

  1. The portal is a pair of objects called GATES that live the same lifespan, each in a different system, each representing the other in the containing system.
  2. A portal constructs necessarily between two existing systems.
  3. The portal is a CONNECTOR between the two systems. As such, it has the same lifespan and volatility as any of the two endpoint systems.
  4. The creation of a GATE may be initiated at one end by system L determines the creation of the corresponding GATE at the other end within system R.
  5. Upon creation, the abstract handle of the left Gate initially holds the ID of system R. The Gate’s handle is abstract in the scope of its container system L. Sucha a gate was constructed in a disconnected state.
  6. A gate must move to a connected state before any dereference is made possible.
  7. Upon connection, a super system E, called the Environment of L and R resolves the gate’s handle by locating the corresponding Gate within the system indicated by the handle. If no such gate yet exists, one would be created in a connected state.
  8. The identity of the connecting gate is convolved into the handle of its counterpart.
  9. Convolving or referencing is the opposite of dereferencing, and is the act of abstracting the location of a persistent object down to identifiers used by more volatile objects.
  10. If E is a network environment, and L and R are networked computers, then the abstract handle of a gate is initially the other machine’s IP address and Port number. Upon connecting, the handle changes to be the open socket between the gates. Upon disconnection, the handle changes from socket back to IP address.
  11. Any object can be a gate.
  12. Portals are connectors. The scope of the connector binds to the environment E.

1.8         Implementation considerations

  1. The gates can be the femurs of a LINE.
  2. The question is now who owns the LINE.
  3. The Network is a unique object which is copied and kept synchronized  on all computers participants to the network.
  4. A network portal binds into the network scope, and links one of its endpoints to the connecting system. The other endpoint is convolved with the reference to the other peer system.
  5. The Portal LINE is an instance of a relation between the two types of the connecting systems.
  6. System L uses system R by logging into it. As a result, the entire content of R is made available to L as its own substance.
  7. Portals are instances of the USES relation.
  8. The Morphic Core tests the children of a scope to see if they are femurs of lines.
  9. A scope is a femur if it is contained in a LINE
  10. USER is a multi connector with a maximal number of endpoints, each testing positive as connector endpoints.
  11. The Schematic Editor is the promoter of such traversals.

1           Portals between Morphic Systems

R: File System

L: Memory System

Type

Strm

Con0

Con1

Rel1

 

            L

 

StrB

Stage 1

B

T'

A

T

$

R

c

p1

p3

p4

p5

p6

p7

p8

p2

Stage 3

B

A

T'

p4

R

c

T

p6

p7

p8

p5

$

p1

p2

p3

Stage 1.1

B

T

p8

T'

A

T

$

R

c

p1

p3

p4

p5

p6

p7

p8

p2

auto

Stage 2.1

R

T'

A

$

p1

p4

p2

p3

p5

B

T'

p4

R

c

T

p6

p7

p8

p5

 

Stage 2.2

T'

B

p4

R

c

T

p6

p7

p8

p5

T'

A

$

p1

p4

p2

p3

auto

File

Mount

Link

 

    R

Type

Strm

Con0

Con1

Rel1

 

 

Converters

 

StrA

Stage 2

T'

A

$

R

lc

p1

p3

p4

p5

p2

B

T

p8

c

p6

p7

rc

   PORTAL

(Important) More than one unary relation generator may exist in a running morphic system at a given time. Let G1 and G2 be two relation generators. A relation such as A contains B reclaims the generation of a relation R from A to B. Since two such relation generators exists in the bodies of G1 and G2, one of them needs to be identified and invoked to construct R. The selectors of R would have different layouts into the user data space depending on whether G1 or G2 generated the relation.

B.                  File System

A.           Memory System

Stage 0

Stage 1

Stage 2

Stage 3=1

Type

Rel

Con

 

Con

MS

 

Type

Rel

Con

Rel FS

Con

FS

 

T

T'

$

R

c

T

T'

$

R

c

T

T'

$

R

c

T''

$'

R'

c'

T

T'

$

R

c

T''

$'

R'

c'

   PORTAL

In the figure above we have two instances of the Morphic System, A and B. The two may exchange substance through a portal. We follow the evolution of some structures of A as they port over to B in four stages.

T

T'

$

R

c

A

T'

T

$

R

c

p1

p3

p4

p5

p6

p7

p8

p2

System A at stage 0 under the microscope:

The above is a normal, frequent case of a type including another.

  1. T and T' are types, uncontained, subsystems in the scope A.
  2. T' contains T through relation R.
  3. R is a unary relation with a unary connector c to T.
  4. Connector c belongs to scope A.
  5. Connector c is included in relation R (hard couple).
  6. Relation R belongs to scope T'.
  7. Scope A has a selector $ of relation R in scope T'.

R is built with two components: a Field and a connector. They form a solid structure through hard coupling. The relation is indivisible.

Connector c and selector $ also have intrinsic components, which are their femurs.

 

Points p1 through to p8 are weak links. For example p8 is a multi-pointer that establish the parenthood of scope A above T. A and T are independent systems which may be decoupled without compromising the integrity of either one of them. The same applies to p1-p7. A special note as far as p2 is concerned: $ is an instance of R, and p2 is a multiple pointer that defines the instantiation relationship. p2 sais that the type of $ is R. This too is a loose link, because it can be severed, without compromising the integrity of $'s frontier, and only loosing its identity.

 

Porting starts with shifting T through the portal. The shifting of a structure is done by recursively porting its included subsystems. If T is indivisible than it is one of the atomic types of the Morphic System for which porting channels have been supplied.

The process of porting a structure from an environment with a certain definition to another environment with a different definition is generally known as Serialization.

Our method of porting a structure has the following particularities:

  1. A structure exists in either one on the environments, and not in both.
  2. A solid structure may be partly ported, so it may exist half in one system, half in another.
  3. A solid structure may overlap more than two environments.
  4. Weak links are not allowed at the level of the portal.
  5. The act of porting of a structure is an act of re-typing it, or a structural morphism.

 

The problem of porting:

  1. We serialized and transferred T across from A to B. This means that T has ceased to exist in environment A and has resumed its existence in environment B. T has had to release the space it occupied in environment A (that space will be recycled by the Morphic Memory Manager) and was given new space to occupy in environment B. This is death followed by a birth for structure T. Since T seamlessly continues to exist, this death+birth, just a blink in T's existence, is called a Port.
  2. At this stage, the objects such as R and c of the source environment A, as well as the ported T itself, have the problem of integrity of their weak links. The weak links formed around T were p7 and p8. Of these two, p8 is resolved by the following convention: a weak link to a Morphic System may be replaced by a link to any other Morphic System. So p8 will be severed from A and made to point to B.
  3. Relation R was pointing to T at one end through its connector c at p7. The pointer to T is now invalid since T is in a different environment with a different addressing scheme, or with a different morphology altogether.
    1. Ex: T has made it out of software and into hardware.
    2. Ex: T has broken out of paper and into software.
    3. Ex: T has broken out of RAM and into the File System
    4. Ex: T has gotten out of machine A and made it to machine B.

T also had pointers back to the femur of the connector c, which are now invalid. Any such pointer needs to be fixed before the port step is deemed complete. This, however would be the wrong approach (must explain why???). Solid complex structures may be partly ported and thus sit on the Portal.

The port will be deemed complete when no weak links are at the level of the portal. This implies that the portal will continue the porting of all weakly linked structures until no such links are pending at the portal. The whole galaxy of dependents may have to shift through as one step of the porting process. The porting relaxes when there are no more dependents, or when  only partly ported structures are pending at the Portal.

  1. The port of T will be deemed complete only when the femur of connector C has also been shifted through the Portal. Only then the portal between A and B can relax.
  2. The connector c of relation R, as well as the whole of relation R unlike any other connector of system A, because it is only partially within A. The femur of connector c must change to hold information about T's location in its new environment B. The porting of B may attract vastly different addressing rules and numeric processing than the source environment has. The femur of connector c must therefore be amputated and another type of a femur must be grafted. The new connector femur must be of a type compatible with environment B. It follows that connector c must be retyped to another Type Master. Because c is solidly contained in R, R also needs to be retyped.
  3. Environment A must provide conversion types ConFS and RelFS to retype c and R to the new femur. We derive the following principle:
  4. A Morphic System must provide a Conversion Type Master for each Type Master whose instances are allowed to cross the boundary to another Morphic System. Depending on the resolution of these Conversion Type Masters, we are able to port an XRef of objects across in smaller pieces and under finer control.
  5. The porting step is still not finished. Under environment B, T must be satisfied with its dependent connector c, which is part of relation R. A relation R with a connector c must be constructed under two Conversion Type Masters RelMS and ConMS of environment B. Just as with the conversion of R and of c under environment A, the new R and c of environment B would hold information about their respective external portions.

 

A' is a FILE. A Morphic File is a Portal into another Morphic System.

For system A to be able to transfer a structure over to B the following must happen:

  1. B must have a set of type masters compatible with A's to at least cover the types of the structure being transferred.
  2. A must have a mirror of those compatible types of B.

For a system A to be able to transfer a structure from B the following must happen:

  1. A must have a set of type masters compatible with B's to at least cover the types of the structure being transferred.
  2. B must have a mirror of those compatible types of A.

Bi-directional transfers are possible between A and B when:

  1. A and B have a set C of equivalent types, and
  2. The structure's types lie completely within the type set C.

1.1         Transfer of substance through the Abstract Neuro Nucleic Aggregate

STREAM is a TYPE generating NODEs.

 

Principles of porting a structure from L to R

1.      All instances of a type must coexist in the same environment as the type itself. It follows that:

    1. porting a type recurses to porting of all its instances.
    2. porting an instance of a type requires the existence of a proxy of the instance's type in the target environment, and the port will retype the instance to the proxy type.

2.      To allow for distributed solid objects, the portals must allow partial porting of sub-components.

 

Stage 0: we prepare to port T from environment L to environment R. T is a subsystem of L, and we want it to become a subsystem of B child of R. B is a file. All objects are typed by the nucleus of system L.

 

We created StreamB, an instance of STREAM and a Type Master generating NODEs.

StreamB is a proxy of MirrorL, which is a collection of conversion Type Masters for nucleus L. Now we want to port all the children of A over to R, as children of B.

 

Stage 1:

  1. L:T is of type Type of L's nucleus.
  2. We create an instance R:T of type "Type" of the Mirror L nucleus.
  3. StreamB interlocks L:T with the location of R:T. The interlock will prevent any other process of L from accessing L:T, which is about to become invalid with respect to L's rules of access.
  4. The exchange of substance between L:T and R:T is carried-out through StreamB to MirrorL of R.
  5. All instances of L:T must now also be ported.
  6. L:T can now be retyped from L:Type to StreamB. Since T may have been a NODE descendent, and therefore larger than NODE, the extra space is reclaimed into the MMM. This extra space is an internal fragment of T. Any XRef to L:T will remain unharmed.
  7. File B contains R:T and all of T's instances ported from L.
  8. Just as every operation in environment L ensures the correctness of its structures, so must the structure correctness be ensured in environment R. Stage 1 will continue recursively until correctness of L and R are achieved, and both L and R are in equilibrium.

 

Stage 2:

The next child of A that we have to serialize is connector c. Connector c, however, is an included component of relation R. The connector c must be ported to environment R while keeping its container R still in the environment of origin. (Principle 2). The port of connector c is done in the following steps:

  1. Construct R:c of conversion type master MirrorL:Con.
  2. Interlock L:c to StreamB with the location of R:c.
  3. Shift across all the substance of c.
  4. Recursing the portal for all instances of L:c is not applicable for connectors.
  5. Retype L:c to StreamB, and reclaim the extra space resulting from the shrink as internal fragment of R.
  6. Decrement T's reference count so that it may eventually be deleted. This is because L:c's femur to T has now been destroyed.
  7. Relation R is now quasi functional, in that it can be skipped, but it cannot be traversed as no other process of L may interlock with L:c. R now has an internal free fragment where the connector's femur used to be.
  8. Under environment R, the new connector c will be bound to R:T using the MirrorL:Con conversion type master logic.
  9. The structure that evolves under environment B is correct at all times, so a third party may already use it, but it still has a different meaning to the structure under L since it isn't completely received. A third party querying R:T would observe that it is selected through the unary connector R:c into B, without having any way of knowing that R:c is in fact a relation of R:T.

 

Hit Counter Created on 05/27/2009 06:34:03 AM, modified on 05/27/2009 06:34:03 AM

Home
Cutting and Cloning
Remote Execution Interface
LINE SerializeSegment algorithm

Home | Feedback | Contents | Search

Send mail to webmaster@ProximaCentauri.ro with questions or comments about this web site.
All principles and artwork exposed on this site or by our software products is our intellectual property. 
Copyright © 2006 Proxima Centauri Romania SRL. Last modified: 05/27/09