|
dispatch is a multi-tier architecture object-oriented framework that allows access to methods and variables at the command line and in shell scripts or via a GUI. The project is in an early stage and you will probably not be able to compile it easily or use it for significant work. There are lots of things which are not documented yet, as they only work occasionally. As the current written code is only a framework, no real application of it yet exists, there are still much things to invent. Get involved. This software package represents a meta program used to manage unix programs. It is a class library in the domain of system administration. It is similar to Microsoft .NET or corba or Unix as it is language independent. Indeed, a method can be written in any language, because the interface of a method is the same as that of a unix command. That means a method is passed an array of arguments, it has a standard input, standard output and standard error channel and returns a small integer exit code. The difference to a shell script is that there is no actual execve system call involved in calling a method, but the method is in a shared object that can be linked dynamically into the running process. With interpreted languages like perl, first the interpreter is dynamically linked into the current process which in turn executes the method written in the target language. That means that the second call of a certain method only involves some lookup in internal data structures to find the already loaded (c++, perl) and byte-compiled (perl) implementation. But this is only half of the story. The power of object orientation to a certain degree comes from the fact that you have abstract interfaces and concrete implementations which are interchangeable to a certain extend. This fact is still true of course, when you map the OO paradigm to the Unix shell and the domain of system management. But unfortunately this principle was not honored by the software that exists on posix compatible systems so far. An example of an interface relating to system management and configuration is internet server software configuration. There a many ways to configure on which port a piece of software should listen. In apache, you write Listen or BindAddress, the tcpserver from ucspi-tcp expects a command line argument, the inetd superserver expects it as the first column of a table in a free-form textfile. It is therefore impossible to know where an arbitrary server listens if you do not write specialized parser code for every configuration file format in existence. It would be so much easier to have an interface that has a method called port that you can call to either query the port or set it. Then you can call the exact same method on any server that implements the interface and dont have to care about syntax rules. Whats New in This Release: - Examples added.
|
Windows Software
Albina Merfyn - I find this to be really easy to use. I can...
