Screens Environment is a multi-platform component based middleware research project designed to connect technologies together and provide better user experiences for the future of computing http://sourceforge.net/projects/screensos/
Sunday, August 08, 2004
Object Storage (Editorial)
You hear about storage systems alot in the news, reviews or even blogs lately...
everyone either reviewing an existing system or designing thier own thoughts of
what a storage system should be like.
However alot of them are very fixed and have specific uses. Some are more dynamic while others are more static but easier to use.
An object storage is more than storing or even finding information. It's about creating a single
design which can encapsulate any information in the world and relate between them in any way needed. This could be anything from inheritence, backup, sharing, attachments etc.
Here is part of my design: (will update as needed)
Screens Environment is based on a powerful, flexible object model which allows representing any information in a connected and global interface.
An object is an atomic unit of information which can represent anything from small name identifiers to huge structures. Each object is indexed for quick searching and has a handle to quickly relocate an object with minimal performance lag. This is done by using the unique identifier of the object in conjunction with the objects index.
Objects alone are not useful; you need to specify relationships between them. Objects use links to specify relationships between other objects.
Both the source and target of a link holds a copy of the link so that both objects understand the direction of the link. An object can have multiple links targeting it or outsourcing it.
Each object holds a name and type identifier to identify the content or linking structure of the object. Each link has a name identifier to identify the type of the link. Together objects and links create flexible resourceful object storage. Each object holds a content stream of any size and unless messages override the read/write capabilities of the object, the stream is stored in the object storage itself.
There are multiple types of links:
1. Container – A container link is the most common link since its very basic and does not do much but define a relationship between a parent object and a child object.
2. Reference – A reference link allows jumping between structures.
3. Class – A class link inherits any objects of the target which are linked via container links even multiple depths of links. Local or extended objects (non inherited objects) override inherited objects.
4. Extended – An extended link allows extending an object structure with another structure however unlike a class link an extended link overrides local objects. If multiple extended links clash, the last extended link prevails.
Because many objects need interfaces to handle them, use method objects. Method objects are normal objects with the link name 'method' and are handled by the system. Because they are objects they can be extended or inherited via links. The name and type identifier of the object is the method identifiers. The method object holds a reference link (type 'code') to the object which handles the actual code. Method objects hold in their structure the parameters that can be sent with the method. If you try and send with non extended parameters they are 'cut' and not sent with the method. This stops 'secret' parameters from creeping into the system. Each parameter holds a name and type and can hold default values if the message did not include them. All parameters should be optional on sending and should be rejected if more information is needed. You don’t send a message to a method object but rather to the source of the method link. The message code finds the correct method handler (either through inheritance, extended or via containers) and finds the code of the method (via the 'code' link) and calls the code directly (native code).
Non native code like java code is done by inheritance. You base the method on the compiler object (like the java object) and all methods are redirected to the compiler object. You can of course override this behavior by basing the object on a different code object which is useful when objects want to switch dynamically between dynamic codes.
An object can exist without methods however its content is static (not dynamic by a method) and is stored in the object storage itself. To override this, just link to a method object with the read/write identifiers. When Screens Environment will try to read/write to the content of the object it checks if any method links exist (either via inheritance, extended or containers) and if not uses system code.
While container and reference links provide a tree structure (parent/child) , the class and extended links provide a way to merge multiple objects together without having to know of the merge (however can be found out if needed). Think of container and reference links as down/up links while class and extended links as left/right links which together allow the full flexibility that the object storage needs.
Applications normally create class objects so that methods are not required for each object instance but rather derive it from the class object. The reason a class is an object is because it increases the flexibility of the storage.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment