I saw a problem lurking which was the callback design for components. There was no way to know when an object was being destroyed unless the component sent a notification. The component could know that its instance is being destroyed but attached objects could not know.
I met this problem in FileToken where it wanted to point to an attached FileChunk instance but would not know if the FileChunk instance was destroyed.
I made a system-wide change. Before, components implemented specific callbacks for constructor, destructor and shutdown scenarios. Now a single handler can be set for each component in its initialization. The handler can receive messages from any component. The constructor, destructor and shutdown scenarios are now sent by CoreObject as messages to the component handler. But now there is a new message CORE_OBJECT_MESSAGE_DETACH which is sent to all attached objects when a object is being detached from it. This will be used by FileToken to know when FileChunk is being detached.
You can find the latest code collection at:
http://sourceforge.net/projects/screensos/files/screensos/packages_002.zip/download
When I hit a milestone, I will add a zip to the source forge files.
Friday, April 29, 2011
Wednesday, April 27, 2011
Moving along
Things are moving along quite nicely.
1. FileChunk that divides files into chunks has been finished.
2. Rewrote CorePool to be a simpler design.
3. Fixed various bugs along the way
I work in a sequence where I write code without testing it and test it at a later date.
Because each component is small, its easier to debug and decide if to re-factor or not.
Next component I am writing is FileToken that uses FileChunk to parse text files into tokens
and after that I get to write FileXml using FileToken.
1. FileChunk that divides files into chunks has been finished.
2. Rewrote CorePool to be a simpler design.
3. Fixed various bugs along the way
I work in a sequence where I write code without testing it and test it at a later date.
Because each component is small, its easier to debug and decide if to re-factor or not.
Next component I am writing is FileToken that uses FileChunk to parse text files into tokens
and after that I get to write FileXml using FileToken.
Wednesday, April 13, 2011
First package source collection
You can find a zipped collection of all the packaged components at: https://sourceforge.net/projects/screensos/files/screensos/
Currently its labeled packages_001.zip
I also uploaded a simple 'author public domain' comment for each file to keep things license consistent.
I am currently working still on the FileXml component. It is taking a little longer than I expected but I am sure progress in the component will come along nicely.
Currently its labeled packages_001.zip
I also uploaded a simple 'author public domain' comment for each file to keep things license consistent.
I am currently working still on the FileXml component. It is taking a little longer than I expected but I am sure progress in the component will come along nicely.
Friday, April 08, 2011
Development in progress
You can find the latest code uploaded via SVN at:
http://screensos.svn.sourceforge.net/viewvc/screensos/
I know that it looks like Screens is not moving anywhere, but there is an actual strategy involved even if it is taking a long time.
Let's recap:
2002-2008 = Wanted an application middleware, researching which programming model to use
2009-2011 = Figured out a new programming model: ComponentC programming model.
In the last half year I have spent time writing components.
The components separate for the first alpha into 3 parts:
1. Core
Core components is the basic core components of the system. CoreObject was the hardest component to write since it represented the programming model for Screens. The other core components were mostly easy.
2. File
This is where I am now. Writing components to parse files including xml using the component oriented model. I just finished a first draft of the file token parser which I will be using now for the xml component.
3. UI
This is the most exciting set of components (after CoreObject) that I want to write. I have had some years of researching drawing models (such as top down drawing) which I want to use in this middleware.
Once I finish these basic set of components, I can start making the more visual demos I made before. There are high and low points in any project. Here I am programming a strong foundation for later on. Once I finish the foundation I will able to move much faster in the alpha and beta releases.
I currently run the code in the iPhone simulator where it deals with multi-touch points, drawing a bitmap for each point while filling the screen with a gradient. As components come by I integrate them and check them in the demo. I think I will have some interesting things to show once I pass the second UI component set.
Because I tended to tell my ideas before implementing them, I am going the other route where I write something and then tell you about it.
http://screensos.svn.sourceforge.net/viewvc/screensos/
I know that it looks like Screens is not moving anywhere, but there is an actual strategy involved even if it is taking a long time.
Let's recap:
2002-2008 = Wanted an application middleware, researching which programming model to use
2009-2011 = Figured out a new programming model: ComponentC programming model.
In the last half year I have spent time writing components.
The components separate for the first alpha into 3 parts:
1. Core
Core components is the basic core components of the system. CoreObject was the hardest component to write since it represented the programming model for Screens. The other core components were mostly easy.
2. File
This is where I am now. Writing components to parse files including xml using the component oriented model. I just finished a first draft of the file token parser which I will be using now for the xml component.
3. UI
This is the most exciting set of components (after CoreObject) that I want to write. I have had some years of researching drawing models (such as top down drawing) which I want to use in this middleware.
Once I finish these basic set of components, I can start making the more visual demos I made before. There are high and low points in any project. Here I am programming a strong foundation for later on. Once I finish the foundation I will able to move much faster in the alpha and beta releases.
I currently run the code in the iPhone simulator where it deals with multi-touch points, drawing a bitmap for each point while filling the screen with a gradient. As components come by I integrate them and check them in the demo. I think I will have some interesting things to show once I pass the second UI component set.
Because I tended to tell my ideas before implementing them, I am going the other route where I write something and then tell you about it.
Friday, April 01, 2011
Eating at a buffet
I finally found how to explain the advantage of Component C objects.
Using Component C objects is like eating a buffet. You have a choice of different foods which you can pile onto your plate in any combination or order that you want.
Using traditional object oriented languages/frameworks is like eating at a restaurant. You have a choice of different meals, each with its own combination of ingredients.
Using fixed meals is easier to use when the choice is small. But it does not scale. There is a reason why sandwich fast food places allow you to choose your own combination. Having a list of pre-fixed combinations becomes messy when it grows more than a few dozen options.
Thats why object oriented examples always work. They are a small selection of classes in use which work great just like a menu with 5-10 items works great as well.
Its when you have to manipulate over 50 items that things become complicated. So then they are separated into categories. But then you get to a point when categories need to be broken down into sub categories. Very quickly things can get out of hand. A complex system may have 200 classes that a developer needs to manage.
Do you derive your class from A, B, C, D, E or the other 50 options. Or maybe you go for containment which defeats the whole purpose of common components since you do not want to have to expose every possible interface that you want to support.
With Component C components. Its a buffet. You only offer a choice but do not control the combination of those choices. If the developer wants to make an object (like a plate) and attach to it (like putting food on a plate) a node and window component, you have a window that can be stored in a hierarchy of other nodes.
While I only have around 20-30 components, the advantage looks small. Its when I reach over the 100 component count that things become interesting. Every component only cares about what it needs to provide a specific feature or part of a feature. The combinations are defined by their usage. It scales.
UIWindow does not have to deal with hierarchy. CoreNode deals with hierarchy. Its separation of concerns. Components stay small because I don't have to stuff every feature I ever need in the same component.
Objects need to support reference count. Instead of stuffing it into CoreObject, it is handled in a separate CoreRef component.
As applications grow bigger, they will need to move to the buffet model. Al a carte.
Just like users are getting tired of fixed 1000 channel selections and prefer to choose what they want instead of tuning to a fixed channel that airs the show they want at a specific time.
Using Component C objects is like eating a buffet. You have a choice of different foods which you can pile onto your plate in any combination or order that you want.
Using traditional object oriented languages/frameworks is like eating at a restaurant. You have a choice of different meals, each with its own combination of ingredients.
Using fixed meals is easier to use when the choice is small. But it does not scale. There is a reason why sandwich fast food places allow you to choose your own combination. Having a list of pre-fixed combinations becomes messy when it grows more than a few dozen options.
Thats why object oriented examples always work. They are a small selection of classes in use which work great just like a menu with 5-10 items works great as well.
Its when you have to manipulate over 50 items that things become complicated. So then they are separated into categories. But then you get to a point when categories need to be broken down into sub categories. Very quickly things can get out of hand. A complex system may have 200 classes that a developer needs to manage.
Do you derive your class from A, B, C, D, E or the other 50 options. Or maybe you go for containment which defeats the whole purpose of common components since you do not want to have to expose every possible interface that you want to support.
With Component C components. Its a buffet. You only offer a choice but do not control the combination of those choices. If the developer wants to make an object (like a plate) and attach to it (like putting food on a plate) a node and window component, you have a window that can be stored in a hierarchy of other nodes.
While I only have around 20-30 components, the advantage looks small. Its when I reach over the 100 component count that things become interesting. Every component only cares about what it needs to provide a specific feature or part of a feature. The combinations are defined by their usage. It scales.
UIWindow does not have to deal with hierarchy. CoreNode deals with hierarchy. Its separation of concerns. Components stay small because I don't have to stuff every feature I ever need in the same component.
Objects need to support reference count. Instead of stuffing it into CoreObject, it is handled in a separate CoreRef component.
As applications grow bigger, they will need to move to the buffet model. Al a carte.
Just like users are getting tired of fixed 1000 channel selections and prefer to choose what they want instead of tuning to a fixed channel that airs the show they want at a specific time.
Subscribe to:
Posts (Atom)