Free embeddable software for linux

BelowVersion is a single-file Python CGI to browse a Subversion repository. It only needs a Web server with Python support and bindings for Subversion libraries.

It bypasses the high-level client library for acceptable performance without losing features. It is written to be fast to navigate with mouse, both within a single revision and between revisions.

It can provide revision logs, colored diffs, and a side-by-side view for image revisions. It can also serve the files like a normal (static) Web server, allowing plain view or saving to disk.

BelowVersion is written to be embeddable in other Web applications with little effort (explained in the source).

Excalibur is an open source software project of The Apache Software Foundation. Our primary product is a lightweight, embeddable Inversion of Control container named Fortress that is written in java.

Inversion of control, also known as the hollywood principle ("dont call us, well call you"), is a simple but powerful concept. The idea is that we dont "wire up" all the pieces that make up an application (the "components") by writing lots of this-component-uses-that-one-like-so code, nor do we use some kind of lookup directory (like JNDI, for example) where each component decides what components to interact with itself. Instead, we instruct a smart piece of software, the container, to tell the components how to interact.

Fortress (and also its predecessor, "ECM") is such a container. It is lightweight, by which we mean that it doesnt need a lot of resources, take a lot of disk or memory, or impose all sorts of demands on its environment. Fortress is also embeddable, by which we mean that you can use fortress inside just about every java environment. More concretely, you can use it as the basis of a large standalone development platform (like the Keel project), at the core of a servlet-based web application (like Cocoon) or even as the basis of a GUI application (like GuiApp).

Fortress knows how to manage components that have been developed using a rigid lifecycle contract called Avalon-Framework. In the next upcoming release, fortress will also be able to manage ordinary javabeans, and support for other kinds of Inversion of Control are planned.

Besides providing fortress, excalibur also provides a small library of very useful components. We also distribute some of the libraries used to build fortress (and some other containers) seperately. This selection of libraries is called containerkit.

So why is excalibur an interesting project?

Heres a few partial answers.

good code. Code that comes from the mature avalon project (everything that used to be branded as "Avalon Excalibur" and "Avalon Fortress"). This includes two lightweight Inversion of Control containers. One of these powers, among other things, Cocoon. The other ("fortress") is the basis of projects like Keel. Excalibur also includes powerful and mature reusable "components" and "libraries", handling tasks ranging from thread management to component pooling to (URI-and-similar-) source resolving.

smart developers. Most of these people are or have been active in the avalon project in various roles. Several of them are apache members. Together they have loads and loads experience under their belts related to inversion of control development. In fact, Im confident to say this list includes some of the biggest experts on inversion-of-control-style container development.

exciting community. Several open source and commercial projects (both at apache and elsewhere) depend on and contribute to the excalibur project. A strong team of enthousiastic developers (with strong ties to several other projects in the same problem domain) has various big and small plans with excalibur. One of the leading open source organisations in the world, The Apache Software Foundation, is hosting the project, providing insight, advice, infrastructure, legal backing, a time- and battle-proven development process, and much more.

HttpdBase4J is an embeddable Java web server framework that supports HTTP, HTTPS, templated content and serving content from inside an archive.

The classes are easy to extend as they utilize the Hollywood dont call us, well call you principle to allow the user to overide the framework behaviour during all the different phases of the HTTP transaction.

Note:HttpdBase4J uses the Java 6 com.sun.net.httpserver classes so it wont currently work under earlier versions of Java.

Usage Examples:

The simplest use case is to create an embedded web server on port 8088 with its home directory at htdocs in the local filesystem and a root url at / ie / maps onto htdocs:

homeDir = new java.io.File("./htdocs");
httpd = new FileHttpd(homeDir, 10); // Creates a server with a threadpool of 10
httpd.setLogger(System.err); // Log to console
httpd.start(8088, "/");

Creating a HTTPS server equivalent the the HTTP server above requires passing a keystore and password to start. Passing null will generate a certificate free keystore if you only need the encryption capabilities of HTTPS and not the certificate capability:

httpd = new FileHttpd(homeDir, 10);
m_httpd.start(8089, "/", keystore, password);

Serving content from inside an archive or from a jar or zip in the Java classpath requires creating an ArchiveHttpd instance instead of a FileHttpd. To serve content located in a jar or zip in the class path you need only specify the resource directory in the classpath where the content islocated, for example:

httpd = new ArchiveHttpd("/resources/htdocs", 10);
httpd.start(8088, "/");

To serve content from within a specific archive specify the archive as a Java File when constructing the ArchiveHttpd:

httpd = new ArchiveHttpd(new File("content.zip"), "/resources/htdocs", 10);
httpd.start(8088, "/");

Creating web content using templates is also supported. Currently only the StringTemplate library (http://www.stringtemplate.org) is is supported but it should be relatively easy to create user derived classes for other template implementations. To create an HTTP embedded web server on serving templated content from resources/htdocs in the classpath and having a template file handler (A Java class implenting the Templatable interface that is used to fill the templates) in net.homeip.donaldm.test.templates.

httpd = new ArchiveHttpd("resources/htdocs", 10);

StringTemplateHandler stHandler = new ArchiveStringTemplateHandler(httpd,
"net.homeip.donaldm.test.templates");

httpd.addHandler(".st", stHandler); // .st extension = template files
httpd.start(m_port, "/");

The HTTP transaction handling can be customized at any point by overiding any of the methods in the HttpHandleable interface or by overiding onCreateRequestHandler in Httpd in order to provide your own request handler. A simple example of overiding HttpHandleable methods:

httpd = new TestOverideHttpd(m_homeDir, 10);
httpd.start(m_port, "/");

class TestOverideHttpd extends FileHttpd
{
public HttpResponse onServeHeaders(long id, HttpExchange ex, Request request)
{
//Create or amend content
}
public InputStream onServeBody(long id, HttpExchange ex, Request request)
{
//Return amended or created content
}
}

Pentaho BI Project provides you with enterprise-class reporting, analysis, dashboard, data mining and workflow capabilities that help organizations operate more efficiently and effectively.
The software offers flexible deployment options that enable use as embeddable components, customized BI application solutions, and as a complete out-of-the-box, integrated BI platform.
Main features:
- The ability to continuously monitor and take action on key performance metrics.
- Linking key performance metrics with the business processes that drive them.
- Solution-oriented approach enabling packaging of BI applications.
- Fact-based decision making and true performance management.
- Improved data accuracy and integrity.
- Better visibility into business processes.
- Shortened business cycle times.
- Ability to analyze results to improve revenues and reduce costs.
- Improved sharing of information and collaboration.
- Ability to meet and exceed compliance and regulatory requirements.
- Workflow-based processes enable you to implement unique business logic for a sustained competitive advantage.
Enhancements:
- Changed to Mozilla Public License
- Added the ability to run reports in the background
- New look and feel
- Support for Kettle 2.3.1 including ability to execute Kettle job
- Upgrade to JFreeReport 0.8.7-9
- Upgrade to Mondrian 2.1.1
- Upgrade from JBoss Application Server 4.0.2 to JBoss AS 4.0.3 SP1
- Upgrade from JBoss Portal 2.0 to JBoss Portal 2.2
- Added If statement support
- Additional reporting samples
- Updated samples to Design Studio conventions
- Refactoring to streamline component API
- Improved auditing to ensure failures are properly captured
- Hidden fields are now supported in the secure filter component

Smalltalk YX software is an open source Smalltalk-80 implementation.
Main features:
- Readable code
- Flexibility trough easy creation of plugins
- Portable to most important platforms
- Optimized
- Modern
- Embeddable in C applications
- Easy to use, powerful and well-structured environment
- Small

Nasal is a language that I wrote for use in a personal project. Ostensibly it was because I was frustrated with the dearth of small-but-complete embeddable scripting languages, but of course I really wrote it because it was fun.
It is still young and incomplete in a few places, but is under active development and has been integrated as the extension language for the FlightGear simulator.
Documentation is still sparse. There is a design document available, which talks at length about the "whys" behind the design of Nasal and includes documentation for the built-in library functions.
More useful to the experienced programmer is the tutorial-style sample code, which explains and demonstrates all the syntax features of the language.
Like perl, python and javascript, nasal uses vectors (expandable arrays) and hash tables as its native data format. This is a well-understood idiom, and it works very well. I felt no need to rock the boat here.
Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks.
Like perl, but unlike python, hash keys must by scalars in nasal. Python supports a "tuple" constant type that can be used as well, but there is no equivalent in nasal (you cant use vectors as keys because they might change after the insertion).
Like perl and python, nasal uses a # character to indicate and end-of-line comment. There is no multiline begin/end comment syntax as in Javascript.
Like perl, nasal functions do not have named parameters. They get their arguments in a vector named "arg", and can extract them however they like. Unlike perl, Nasal takes advantage of this feature to do away with function "declaration" entirly; see below.
Like python, there is no hidden local object scope in a function call. The object on which a method was called is available to a function as a local variable named "me" (python calls this "self" by convention, but because nasal has no declared function arguments, there is no opportunity to change it).
Like perl, "objects" in nasal are simply hash tables. Looking an item up by name in a hash table and extracting a symbol for an object are just different syntax for the same operation (but read on for an important exception):
a["b"] = 1 means the same thing as: a.b = 1
The above paragraph is a minor lie. The "dot" syntax is also the clue to the interpreter to "save" the left hand side as the "me" reference if the expression is used as a function/method call. That is, these expressions are not equivalent (one is a plain function call, the other a method invocation on the object "a"):
a["b"](arg1, arg2) isnt the same as: a.b(arg1, arg2)
Like javascript, nasal lacks a specific "class" syntax for OOP programming. Instead, classes are simply objects. Each object supports a "parents" member array; symbol lookup on the object at runtime bounces to the parents (and the parents parents) if the symbol is not found in the hash. The parents field is just like any other object field, you can set it however you like and even change it at runtime if you are feeling especially perverse.
Like lisp, javascript and perl, nasal supports lexical closures. This means that the local symbol namespace available to your function when it is assigned remain constant over time. If you dont know what this means, you dont need to care. It is this feature that allows functions to use variables declared in the outer scope when it is defined (e.g. seeing "module" variables).
Like all other scripting languages, functions are just symbols in a namespace, but unlike all other scripting languages, there is no function "declaration" syntax. A function is always an anonymous object (a "lambda," in the parlance), which you assign to a variable in order to use. Like so:
myfunction = func { arg[0] + 1 }
myfunction(1); # returns 2
One annoyance of this feature is that Nasal functions dont have unique internal "names". So a debugging or exception stack trace can only give you a source line number, and not a function name as reference.
Nasal has a straightforward, readable syntax which is closest to javascript among other scripting languages. Like later versions of javascript, it includes has a hash lookup syntax as well as an object field accessor syntax (that is, you can do both a.b and a["b"]).
Unlike python, nasal has a grammar which is not whitespace-sensitive. This doesnt make python hard to write, and it arguably makes it easier to read. But it is different from the way the rest of the world works, and makes python distinctly unsuitable for "inline" environments (consider PHP, Javascript, ASP or in-configuration-file scripts) where it needs to live as a plain old string inside of another programs code or data file.
Nasal garbage collects runtime storage, so the programmer need not worry about manual allocation, or even circular references. The current implementation is a simple mark/sweep collector, which should be acceptable for most applications. Future enhancements will include a "return early" capability for latency-critical applications. The collector can be instructred to return after a certain maximum delay, and be restarted later. Fancy items like generational collectors fail the "small and simple" criteria and are not likely to be included.
Like python, nasal supports exception handling as a first-class language feature, with built-in runtime-inspectable stack trace. Rather like perl, however, there is no special "try" syntax for exception handling, nor inheritance-based catching semantics. Instead, you call a "try" function on another function, and inspect the return value on your own. Code simply calls die with an argument list, which is returned from the closest enclosing try() invocation. Elaborate exception handling isnt really appropriate for embedded scripting languages. [NOTE: this isnt finished yet]
Nasal tries to be stricter than perl. Operations like converting a non-numeric string value to a number, reading or writing past the end of an array or operating on a nil reference, which are generally legal in perl, throw exceptions in nasal. Perl sometimes bends over backwards to do something "reasonable" with your instructions (e.g. whats the boolean truth value of a hash reference?); nasal doesnt try ("error: non-scalar used in boolean context at line 92")
Nasal is very small, very simple, written in ANSI C, and generally an excellent choice for embedded applications. It uses a simple and transparent syntax interpretable by a simple "bracket matching and operator precedence" parser. It does not depend on any third party libraries other than the standard C library. It does not depend on third party tools like (f)lex and yacc/bison. It builds simply and easily, supports a reasonably simple extension API and cohabitates well with other code.
Nasal makes no use of the processor stack when running recursive code. This is important for embedded languages as it provides the ability to "exit early" from a Nasal context. An outside application may have realtime constraints, and Nasal can be instructed to run for only a certain number of "cycles" before returning. Later calls will automatically pick up the interpreter state where it left off.
Nasal provides "minimal threadsafety". Multithreaded operations on Nasal objects are safe in the sense that they cannot crash or corrupt the interpreter. They are not guaranteed to be atomic. In particular, poorly synchronized insertions into containers can "drop" objects into oblivion (which is OK from an interpreter stability standpoint, since the GC will clean them up normally). Race conditions have to be the programmers problem anyway, this is just another symptom. Garbage collection will block all threads before running. [NOTE: this part is still unimplemented.]
Enhancements:
- This release contains the updates that have been available in SimGear for some time now.
- Important new functionality includes bugfixes, many performance enhancements, a declared function argument syntax, a ternary (?:) operator, indexable and mutable string objects, interpreter thread safety features, and much work to the "standard" library (including stdio, bitfields, Unix system calls, and PCRE regular expressions).

C++ Portable Components project are a collection of open-source class libraries that simplify and accelerate the development of network-centric, portable applications in C++.
The libraries integrate perfectly with the C++ Standard Library and fill many of the functional gaps left open by it.
Their modular and efficient design and implementation makes the C++ Portable Components extremely well suited for embedded development, an area where the C++ programming language is becoming increasingly popular, due to its suitability for both low-level (device I/O, interrupt handlers, etc.) and high-level object-oriented development.
The C++ Portable Components help developers to focus on the unique core features of the product they are developing ? the features that will ultimately sell the product. By reusing the tried and tested components provided by the C++ Portable Components, developers do not need to waste valuable time and resources re-inventing the wheel.
C++ Portable Components Layers
The classes provided by the Applied Informatics C++ Portable Components provide support for:
- threads, thread synchronization and advanced abstractions for multithreaded programming
- streams and filesystem access
- shared libraries and class loading
- powerful logging and error reporting
- security
- network programming (TCP/IP sockets, HTTP, FTP, SMTP, etc.)
- XML parsing (SAX2 and DOM) and generation
- configuration file and options handling
- an embeddable, lightweight SQL database
Todays highly complex software systems often outlive the hardware platforms they have originally been built on. Applications based on the C++ Portable Components can be easily ported to a new platform, thus helping to save and increase the return on investments made in software.
Enhancements:
- This release contains major bugfixes and performance improvements in the HTTP classes.

KLone is a fully-featured, multiplatform, web application development framework, targeted especially for embedded systems and appliances.
It is a self-contained solution which includes a web server and an SDK for creating WWW sites with both static and dynamic content. When using KLone, theres absolutely no need for any additional component: neither the HTTP/S server (e.g. Apache, Netscape, Roxen), nor the typical active pages engine (PHP, Perl, ASP, Python).
KLone project does everything, and does it fast and small.
KLone blends the HTTP/S server application together with its content and configuration into a single executable file. The site developer writes his/her dynamic pages in C/C++ (in usual scripting style: < % /* code */ % >) and uses KLone to transform them into embeddable, compressed native code with the native C/C++ compiler. The result is then linked to the HTTP/S server skeleton to obtain one single, ROM-able, binary file. This means that he/she can get:
- easy, complete and unfiltered interaction with the host operating system
- dynamic pages in native compiled code, which in turn implies
- fast execution and
- small overall application footprint [1]
- all of this without giving up the common functionality of web application frameworks such as sessions, parsing of form variables, cookies, etc.
Enhancements:
- A newline is always added after < %! % > C translated code.
- Posted data can have content-length equal to zero.
- Unmatched single or double quotes in kl1 blocks no longer cause compilation errors.
- SA_RESTART is used for all signal handlers to avoid EINTR when calling syscalls from within .kl1 pages.
- More console messages are printed on startup errors.