I would like to discuss what XteNetX is all about. The name of the company was hard to come by at first. I was looking for something that would describe the vision behind the products that we design. So I’ll try to explain.
The X at the beginning and end of the name XteNetX implies the interconnected nature of the design philosophy of the company. The next 5 letters are a combination of the word “Net” and indicate how we plan on interconnecting our products with the world around us. The “Net” is initially spelled backward and then forward, sharing the letter N. The name of course looks the same reading it forward or backward. I know, it seems silly, but I like things to be symmetrical.
I’ll make an attempt to help with the pronunciation of the company name XteNetX. It sounds like “X 10 Net X” and sounds pretty close when you say it quickly.
So to be more specific, XteNetX is a company that will focus its energy on designing software products that help software developers build software solutions that work on a single computer or across a network of computers.
Thank you for your time.
I think I would like to talk a little about ScriptBox and describe what it is. ScriptBox is much more than a C# or VB.NET source code compiler. It is a free-standing service provider that not only compiles each script and places the script in its own protective domain, but provides additional services to the running scripts or components.
If you look around on the internet you can find .NET script compilers, but you can’t find a runtime environment that provides services like ScriptBox. ScriptBox has embedded into its core a set of services that provide two easy to use communication channels. These channels are referred to as “Local” and “Remote.” The local channel refers to the ScriptBox running on a local machine and the remote channel refers to ScriptBox running on another network computer. But in reality either bus can point to any local or remote computer running ScriptBox. In my mind it simplifies the concept initially to think about local or remote channels.
The true power of this runtime environment can only be seen by experimenting with ScriptBox. Download the “Express” version and run the example scripts included to get started. Also, look at the documentation provided to see how the API works.
ScriptBox is so much more than a simple compiler, but rather a digital assistant that can enhance your creativity when building new software systems that are like no other.
Thanks for listening.
ScriptBox 1.10 was released in February 2011 and I would like to talk a little about the current update. Version 1.10 of ScriptBox was designed to add additional functionality to the API and make it easier to control scripts/components.
The components that are run by ScriptBox are referred to as scripts and I think that causes some confusion. The term “script” is simply a way to describe how easy it is to compile and load components into ScriptBox, almost as if using a scripting language from the command prompt. “Scripts” are fully functional programs that can be compiled directly by Visual Studio with only a few minor changes.
ScriptBox has been evolving into a powerful software assistant for developers. Version 1.10 has added a series of new API methods for creating more powerful components. The expanded API has added new methods for script control and many of the methods from version 1.00 have been modified to return a value from the call.
The concept of a “Trigger” was added to version 1.10 that provides a method of loading scripts based on triggers that are sent to ScriptBox. Triggers provide for dynamic loading of scripts to handle events or logic that requires additional assistance. Look at the “ScriptBox API Programming Guide” for more details on the new features.
ScriptBox 1.20 was released in April 2011 and several enhancements have been added to make ScriptBox easier to control remotely. A new management application is now included with ScriptBox that makes loading scripts as easy as dragging and dropping them on the application. The new management application can display four internal lists from each ScriptBox: assemblies used by scripts, messages, running scripts and system settings.
Keep watching for enhancements to the management application over the next few months, I think you will like what you see.
Thank you for your time
ScriptBox has been slowly evolving into a simple to use but powerful environment for managing multiple components running in memory. New methods have been added to assist in the management of components that are running across multiple computer hosts. ScriptBox has many powerful built-in features that can assist with managing parallel processing and fault tolerant features across components.
I sometimes worry that the simplicity of the ScriptBox environment will keep some users from exploring the powerful features that are available. A large amount of time has been spent on the design of the runtime environment to assure users that the system is robust.
Several tools are used internally to scan the source code for coding issues and a growing set of API tests are used to verify the operation of the runtime system. During testing of a new ScriptBox release, many thousands of components are loaded and unloaded from memory looking for problems with the runtime system.
I know that no software system is entirely perfect, but I promise to continue to make ScriptBox and other software elements at XteNetX as defect free as possible. So please let me know if you find any issues or if you have any suggestions to make our products better.
Sorry about the long gap between updates for ScriptBox but the system has been changing over the past few months. ScriptBox started out as a simple run-time environment for building small to medium sized multi-threaded applications. Now ScriptBox is changing once again. ScriptBox has changed it’s name to ComponentManager to better describe the future development work on the system.
Software development can seem to be a moving target at times. Multi-threaded programming is more the norm today than ever before. ComponentManager is just one way to help move developers toward designing multi-threaded, multi-computer network connected applications. ComponentManager will also provide a simply method for adding a level of fault-tolerance to any distributed application.
I hope you like the direction that ComponentManager is moving in and I hope you will give the system a try. I guarantee it will simplify the way you build the next multi-threaded, multi-computer, self-healing, distributed system.
As always, Thank You for your time