About the effective usage of components and our aims with ActiveX Pack1 and the other related components. 

In the last 10 years the component based development became gradually a popular topic. However many developers are disappointed by it. The main reason for the negative impact on the developers are the problems with the components. For example it is about the bugs, lack of support for new features in the covered area, limitations, different APIs with different components etc. In general the problem is that the boxed solution is very good and time saving until it leaves you helpless to do anything to correct a problem in it or add missing/new feature.

It seems that the issue is not a general problem of the component based software development, but it is most likely a side effect of the fact that most of the component developers are trying to offer final/complete solutions for certain tasks. This is often unwise or needs too much support, or just the standards involved are changing too often, or are not very clear. Sometimes the component is perfect but not convenient for all the applications and so on. So, the problem is most likely a matter of the level of the universality of the components.

One good example many developers know are the HTTP upload components - very often such a control is build not paying attention to all the specifics of the different browsers and client OS-es - for example the text lines of the headers are expected to finish like in Windows and uploads from some Unix machines are not processed correctly. Similar and even worse is the case with components built to support certain file formats etc.

Some developers begin to think that the component development (in general not in particular project/company) should rely on multilevel componentization. In other words better results can be achieved by separating the components in categories - low level, middle level and may be application level. If the features supplied by the low level components allows the particular tasks to be implemented with acceptable efforts it is possible over one set of low level components to build code that performs quite many different tasks. This code can be considered component of middle level. If we us as an example the upload mentioned above, we may have low level components supporting streams with powerful binary search features and control over the basic level encoding, then we may have one or more libraries/components that use the low level to implement upload processing steps, but we may have also other tasks implemented with the same low level components - such as e-mail messages parsing, information extraction tasks (from MP3 files for example or from DBF files and so on). The middle level code can be written even in script not losing considerable amount of productivity because the most processor power consuming tasks are still performed by the low level components which can be optimized/written in language better for low level processing (such as C++).

Thus we can think for it as of some kind of a technique positioned between the pure boxed (component based) development and the open source. Yes, the open source could coexist with component based development, but in the real life it often leads the developer to too much customizations and the boxed nature is lost in the process. So, the balance seems to be the best way - we can still change the middle level or we may choose to pack and box it too, but we are able to separate the layers and solve most of the problems in the middle. If the low level components are well planned then the middle level rarely needs too much code and it is not a problem to redistribute it, also it is much easier to write such a code for a particular task compared to writing everything from scratch. If the low level allows the developer of the middle level to concentrate on the task then we are almost here.

This is not something new. In fact it is the well-known old programming over run-time libraries. We just claim that the best way to plan and implement components is position them clearly in the correct layer for them and build the low level components as run-time libraries, the middle level as open code or as lightly packed components, libraries, includes (as appropriate).

Our aims with ActiveX Pack1 and other projects are to offer multipurpose low level components and not just give final and boxed solutions. For example with SFStream alone or together with some of the other components suitable for binary data processing upload processing class/library/activex can be implemented in less then 100 lines of script code (even with advanced helpful features) and then reused in many applications. This is relatively easy and the performance is almost the same as the performance of an upload handler written entirely in C++. But most ASP developers are able to understand the code of the handler (Which is written for example in VBScript/JScript) and they are able to correct it, add specific features etc. If something is missing most scripting developers will be able to add it by just altering the script, there could be many implementations of the same functionality in different languages, for different applications, adapted for certain requirements and still one may use this middle level code without the need to understand it, but if such a need occurs it can be done with very little effort.

We offer Binary data processing components (SFBinaryData, SFStream, SFFilter), record based data access components (SFRecord/SFField), Dictionary collection components (VarDictionary/ConfigFile) to help the developer keep structured data internally or exchange it. Script hosting components (ScriptManager2, ScriptAggregate), script based COM object building (Composite objects) and so on. This is a construction kit, still many often needed low level operations are implemented in its components and writing script utilities/includes/libraries based on it will not cost too much to the performance, but allows this code to remain open enough for changes when they are needed.

In future we will continue this way. We will fill the gaps add features (mostly in other libraries) and so on. Today many people are saying that .NET or/and Java will make such things unneeded. Still the practice shows that the traditional way with different development tools for each level has its benefits and is much safer and effective. In fact it is still not clear if a single development tool can be built that will be good for all the levels - low level, middle level, application level. The portability promised by the so called managed environments (Java, .NET) is often compromised by the differences of the platforms where the engine runs the code, the requirements to the hardware rise. And so our target is in the middle - something more than a scenario where you have only scripting or only C++ and something less then environments that tries to "cover all the needs of the world".

Separating the components through levels also makes the bugs much less probable. When a low level component is written it is tested by itself. Each of its functions is not something that produces useful final result in one step, but can be tested alone. Thus it is much easier to test and debug the libraries at each level separately and there are just less places where one can make a mistake.