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.
Wednesday, April 27, 2011
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.
Saturday, March 19, 2011
Updates committed
Just to let you know that the latest code has been uploaded into the ScreensOS repository.
Friday, March 18, 2011
Moving along
Hi,
Sorry that I am consistently late in my updates.
I have been writing loads of components such as CoreQueue, CoreState, CorePool.
I am expanding the components and fixing bugs as I find them in existing components.
My next component is FileXml which will manage xml in an object oriented fashion but will have a twist where the objects are allocated by the caller instead of by the component itself. The xml file will also only be partially processed as needed. This should allow to load huge xml files without having to have the memory overhead.
There is currently a bug I think in XCode 4.0 where I can't seem to save my password in the repository settings for my SVN repository. When I find out how to save the password, I will update the latest code.
Sorry that I am consistently late in my updates.
I have been writing loads of components such as CoreQueue, CoreState, CorePool.
I am expanding the components and fixing bugs as I find them in existing components.
My next component is FileXml which will manage xml in an object oriented fashion but will have a twist where the objects are allocated by the caller instead of by the component itself. The xml file will also only be partially processed as needed. This should allow to load huge xml files without having to have the memory overhead.
There is currently a bug I think in XCode 4.0 where I can't seem to save my password in the repository settings for my SVN repository. When I find out how to save the password, I will update the latest code.
Subscribe to:
Posts (Atom)