The Unified Object Model

This document documents a design for a "unified object model" where everything in an operating system can be represented as an object. An "object" is a collection of related properties and actions; "properties" are things like the contents of a file, the position and size of a window on the screen - they contain data - and "actions" are the things that an object can do, such as a program object which can run, a button which can respond to being clicked and so on - they contain executable code. Actions can be executed either in response to an action by the user, in response to something inside the kernel, or by another object's action (the kernel is probably just a large collection of objects and sub-objects with loads of actions anyway - in any case all three methods of activating an action are probably done through the core of the kernel anyway (actually I think that the kernel can only deal with objects and all the other things like drivers and things are done as normal objects - I think that this is called a microkernel actually for that matter).

Objects live in a heirechical structure with the element at the top being not an object but a "domain" (I need a better word here to avoid confusion with website addresses - maybe "namespace" would be a more technically correct term?). Domains are places where objects can be stored - particularly memory and disk space (there is no distinction here between objects stored in memory and objects stored on disk but the program which creates the objects needs to decide where would be an appropriate place to store them considering the different attributes of volatile and non-volatile storage - objects could even be stored in ROM (although new ones obviously couldn't be created in ROM) although that is not likely to be appropriate for a PC operating system though). Objects have parents, children, and siblings (At the moment there is uncertainty as to how this can be implemented - either it could be implemented by giving each object a link to its parent, first child, previous sibling and next sibling; or it could be implmented where either an item is a subdomain (which cannot contain properties and actions like objects can but it can contain objects) or an object (which has properties and actions but cannot contain objects lowerer in the heirachy). The former option is by far more logical and useable but is less efficient to implement - this leads to the question of if "domains" should exist at all or if "domains" should be replaced simply be top-level objects although that doesn't seem like a good option at the moment.). An object is referranced by a name and path of the form "domain.grandparent.parent.object" - the best way to implement this at the moment seems to be with links as per the first option given in the brackets above. The properties of objects are identified by a comma after the object's full name (including the path) and the actions are identified with a colon; both can also be refferanced using the full name (including the path) and the property/action name as seperate parameters.

Thus all objects must at least have the following properties (objects are not required to have any actions):

	object,name
This is the name of the object; internally objects are given numbers which can also be used to refer to them (numbers are always the same for a given object but the same number can be re-used across multiple object paths and if an object is removed another one might later get the same number) but the name is normally used unless for efficiency to avoid having to look the name up multiple times. (Actually maybe the name should not be a property of the object but be the object's real identifier like how the names of properties are their identifier and not a property of a property (properties don't have a heirachy anyway) - we could still allow the dynamic allocation of "object handles" to requesting programs for efficiency if we did that.)
	object,type
This is the type of the object; again types are given numbers which can be used (although the numbers can change between "registration" of the types - an action which occurs when the kernel comes across an unknown type name - because they are assigned dynamically) but the name is normally used unless for efficiency to avoid having to look the type name up multiple times. (Actually some types might just get a number - things like files and such which are defined by the system - or they could have names but come "pre-registered" with the kernel at system startup. Or should all types get a number and we scrap names? (Although that could lead to conflicts but we'll get those with names anyway. I really need to sort this one out as well...))
	object,parent
This is the ID number of the object's parent.
	object,child
This is the ID number of the object's first child (this is thought to be the one created first and thus with the lowest ID but this may change).
	object,next_sibling
This is the ID number of the object's next sibling in the sibling list.
	object,previous_sibling
This is the ID number of the object's previous sibling in the sibling list.

Files are objects as well, and any file object is expected to have the following additional properties:

	object,data
This is the contents of the file; any object can have data associated with it (and the "object,data" property should be used whenever abstract data is associated with an object) but file objects are required to have this property even if they are "empty" files (as they are called in the common sense).

Directories (commonly known as folders) are simply objects with no extra properties or actions - their children are usually files but may be any kind of object (you could save a GUI heirachy into a directory to load from disk for example, but you could not save it into a file). (Perhaps this concept could/should be taken further?) (Alternatively directories are files with no data property or are a more system-wide container-style object - can a file be a child of another file?) (I really need to decide about this thing...)

Executable programs are objects which are expected to have the following actions (but are not required to have any additional properties):

	object:run
This action is called by the kernel and should start the program running. The exact details of this are unknown (such as regarding multitasking and such things like that) but it should do the work of running the program (possibly with the help of other objects and/or actions or by setting up objects with actions which can be triggered by the kernel or user and then terminating itself leaving itself to be disposed of by some other action - this approach could be good for GUI programs and device drivers in particular).

Any object can be drawable on the screen by supplying an "object:draw" action which is then called by the kernel when the object needs to be drawn (the way in which the object draws itself is another matter - this is going to be used for GUI objects (widgets I think those are called)). (At this point it might be worth adding that an action can be a link to an action belonging to another object, so for example not every button object does not need to have its own "draw" action; they can link their "draw" actions to some kind of a "template" button whilst still having their own properties for their size and things like that.) A drawable object is also expected to have the following properties:

	object,position
This stores the position of the object (the exact details of this are unknown - it might actually be implemented as two seperate properties for the two co-ordinates) on the screen.
	object,size
This stores the size of the object (the exact details of this are unknown - it might actually be implemented as two seperate properties for the two dimensions of the object) on the screen.

Note that the measurements are done reletive to the parent object. In the event that the parent object does not have those properties (the parent object is thus presumably not drawable, although a non-drawable parent object which does not have a "draw" action can still have these properties) then the desktop position and size is used (there might be other approaches here such as using values supplied dynamically by the kernel or by the object's domain). If an object goes outside of its parent's screen space then it is clipped (as should be any drawing done by the "draw" action which does not stay within the object's allocated screen space as per its position and size properties).

Obviously any object can have extra properties and actions as required by the object or by any other objects which use it. For example a GUI window object would need to have a z-order property for use by the kernel (or perhaps I should say window manager because I was supposed to be making it a microkernel actually so then it couldn't be in the kernel) or a music file on a disk might be a file object but have properties storing its duration and composer (note that files can be of various subtypes - how these will be implemented is currently unknown, maybe files need an extra property associated with them - but that executable programs are not actually file objects (although they can have data associated with them and be stored on disk (in a directory?) just like any other object can be).

It might also be worth noting that with regards to traiditional programming concepts "variables" would need to be implemented as objects as well - probably but not nessecerially stored in the same domain as the program which is executing (programs should be copied into memory before being executed because the x86 archietechture does not allow the execution of programs directly from disk and that would be very slow and wear the disk drive out very quickly anyway - note also that in some strange setups one could theoretically have multiple memory domains (actually that could be useful as a way to get around memory fragmentation or at least to avoid the ISA memory hole but that would seriously complicate the kernel - yes I think I actually do mean kernel this time) and then the variable would be put in the same domain as the program code (well probably anyway although the program can choose where it wants to put the variable - it could store it on disk as non-voliatile data, in fact program settings and such data which might be found in the Microsoft Windows Registry system could be stored on disk as child objects of an executable program object)).

Anyway this does offer quite a few interesting ideas and possibilities but it does seem quite complicated to implement and there are a few finer details to decide on before attempting to implement this and the decisions made there could drastically affect the outcome and the complexity of getting to that outcome and I don't work well with code where I don't know where it's going but this is an interesting idea which I wanted to write down but I'm battling to get it down because I don't know if I've covered everything and it's so frustrating when the ideas are all there in your head and you can think of them all of a sudden when you need to but you can't write them down in a way that you would understand if you completely forget the ideas or in a way that someone else would understand but then that's what happens when you can't think of complex ideas in terms of words and you can completely understand the concept but you don't think of it in terms of words and words are a really painful way of thinking because they are very slow and you can imagine a very complex idea in a split second but you can't express it in words because you can't think of complex ideas in terms of words and there's a lot more detail to the idea than you can put in words but I've put it in words here but I wish I could just do a disk image of the partition in my brain where these ideas are stored so that I can get them back again in a format that I can understand in case I ever forget them because I can't understand complex ideas like these in terms of words and it's so annoying when you're trying to understand something that someone else has explained and they've explained it in words because I can't follow complex explanations in words because they just become a big muddle because I don't think of them in terms of words.