New Object Storage

OK, Here we go again...

My latest evolution of the object storage is as follows:

Each object can contain an instance per component.

This means that a markup object can contain the following instances:

UIMarkup - Html markup instance for display

FSHtml - Html parser instance

FSXml - Xml parser instance

FSFile - File stream instance

The idea is that the markup object is also a markup object, also an xhtml file, also an xml file, also a file stream and so on.

These components are attached at run-time to an object and there are no rules on attachment.

You create an object using CoreObjectNew, retrieve an instance using CoreObjectInstance, destroy an object using CoreOjectFree and store a handle to an object/instance using CoreObjectStore.

Here are the prototypes:

bool CoreObjectNew(CoreObject ** ppObject);

bool CoreObjectFree(CoreObject ** ppObject);

bool CoreObjectInstance(CoreObject * pObject, CORE_OBJECT_CALLBACK callback, uint32_t size, void ** ppInstance);

bool CoreObjectStore(CoreObject ** ppLocation, CoreObject * pObject);

Its a lot to swallow but once you understand it, its very easy to use.

The object does not contain the instances, the object is an instance. You can just cast any instance directly to a CoreObject pointer. To cast an object to a component you use the component's cast function like this:

UIElement * pElement;

CoreObject * pObject;

CoreObjectNew(&pObject);

UIElementCast(pObject, &pElement);

UIElementMove(pElement, 50, 50);

UIElementResize(pElement, 100, 120);

UIElementShow(pElement, true);

You can also use the shorthand New method on a component as follows:

UIElement * pElement;

UIElementNew(&pElement);

UIElementMove(pElement, 50, 50);

UIElementResize(pElement, 100, 120);

UIElementShow(pElement, true);

The advantage of this design is that each component does only what it needs to and allows objects to be passed freely between components. Each component can access only its own instance on an object so there is complete data hiding.

I have finished writing the object storage and I am now going to start working on UIElement which deals with drawing to the UIDisplay component. I know that previous demos were slow, so I am seeing what I can do about baking drawing performance directly into the new design.

If you have any questions, ask away...

To answer currently know questions:

1. I will be testing the code on the PalmOS simulator, if I found that I have a valid code base (a.k.a demo code) I will try get my hands on a PalmOS device to test it out. So yes, there will be a platform dependent code base for PalmOS.

2. I don't know when Screens will be released, my curse is that I am a perfectionist and feel that there is no point releasing just another middle ware if I have nothing unique to show. I have a rule that if some code is hard to write, the design is probably wrong. So far that has been the #1 reason for all the rewrites over the years.

3. The drawing model for Screens is like a markup model, you create elements, fill in thier properties and the display draws them by itself. This is like the WPF model, not like the GDI model in windows.

4. I don't know if Screens will be ported to Linux/MacOS, but I don't see any problems doing so in the future. The platform dependencies are a minimum. If I get passed the previous demo I showed last april, then I will be buying a Mac for porting purposes to the iPod touch.

Enjoy!

Update: 26 and learning

Hi anyone who still checks this blog,

I now I have not updated for a long time. I moved to Jerusalem with my family, had a lot of work to do at my full time job and my son started kindergarden. Alot has changed since I first started Screens is 2001.

Screens is not dead, actually on the contrary... I never stopped working on Screens and have in fact tested a few of my ideas at work and they have worked really well.

I am very happy with the component object model and do plan to start writing code again. I don't have my lifedrive anymore but the code should be usefull no matter where it runs.

Once I start getting into coding again specifically for Screens I will update you and write some editorials... I have alot of them down the pipeline, so keep tuned...

Zakai Hamilton

Random Thoughts

1. Don't rely on a compiler extension when doing platform indepedent code

You will never know when your code will hit a compiler you did not anticipate. Keep it cleanand simpleand don't try to be smart. Consistency is key in writing alot of components. Avoid using tricks because their value will decrease over time because you will lose track of the tricks you used.

2. Using a 'better' language (C++, C#) will not reduce the real complexity which is the number of components you need to write and thier dependencies and relationships.

3. Consistency in API function and component naming is sometimes more important than the implementation itself since the implementation can be refactored while an API mostly cannot be changed.

Just a few things that come to mind when writing code for Screens. I am still active on the project and spend between 1-2 hours a day on Screens now thanks to my HP Mini-Note 2133.

I have not got to the graphics code just yet, but I am very close to try it out.

Why is Screens is taking so long?

Screens Environment has been going since 2002 and still no releases have made the light of day. There is a single reason why Screens has taken so long and why I have no idea when it will be released. Its not because I lack time or interest. Its because of the object storage.

If you look at the object oriented OS projects, none of them have made mainstream because they are not practical enough, too complex, too slow and still stuck in a concept. There are many companies trying to bring object oriented concepts to file systems just like me and just like me are still stuck.

If I was not making the object storage, I would of finished Screens long ago but then again the object storage is such a radical change that Screens would not be the same without it. In fact, the object storage would be the main difference between Screens and other middleware platforms.

I need luck, time and persistence to find a combination that works.

Component Oriented Programming

The difference between component oriented programming and object oriented programming is focus. In object oriented programming the focus is the objects themselves which is why you access methods through objects like this:

CoreObject * object = new CoreObject;

object->rename("My Object");

In component oriented programming the focus is the components and objects are just placeholders for instances like this:

CoreObject * object = CoreObjectNew();

CoreObjectRename(object, "My Object");

It looks like procedural programming but the difference is that it uses objects. One of the reasons object oriented programming has never able to become a file system is because when objects are created, they are stuck in stone in their definition. While their properties can be modified, you cannot add/remove properties. In component oriented programming, an object is just a placeholder where you attach/detach components to objects. Each component has a data definition associated with it. Because of this, when you attach an object to a component, you attach private data of the component to the object. Each component only accesses its private data per object and does not read or write another component data directly but rather uses the API provided by the other components.

That is component oriented programming in a nutshell.

Twitter

I am going to try and use twitter for quicker updates on development and keep the blog for more milestones and other news,

follow me at http://twitter.com/zhamilton1 for some live development updates on how code is the Screens code is evolving and the issues I face daily.