Problem
I know C and the OS' API. I have a good idea for an application, but making it involves a bit of boring logistics. I don't want to reinvent wheels and stuff.
Problem
I'm having a hard time choosing appropriate data storage and communications models for my application.
Problem
I don't have efficient and tested code for logging, buffers, markup languages, configuration file parsing, daemon processes, CGI, etc.
Solution

Flux
Package
Browse CVS
Browse FTP
Download
Documentation
Plans
Platforms
Authors
Token trees
Markup trees
Logging
Sockets
Communications
Proxies
Contact
Public mailing list
Maintainer
(hpj@styx.net)
License
GNU GPL
(free software)
Related
FIDEL
Conglomerate
Simplemente

Important notice

The current Flux version released for download is 0.2.8. I'm working on 0.3.0, which should be ready in a few days, and the documentation you see here is for that version. Its API is vastly different from 0.2.8's, setting the standard for all future releases.

As such, if you want to spare yourself some pain, don't use 0.2.8 in current code. Thanks.

Pre-0.3.0 is in CVS, though, and you can get it with the following sequence of directives:

> cvs -d :pserver:anonymous@cvs.styx.net:/cvs login
(Logging in to anonymous@cvs.styx.net)
CVS password: [blank password, just hit enter]
> cvs checkout flux

Background

Even the smallest program operates on some kind of data, reading and writing structured formats. Larger (though not necessarily large) programs can have features like event loops, interprocess communications, buffers and logging facilities.

Programming or piecing together this per-program framework can be a tedious and time-consuming duplication of effort. You want to spend your time on an application's unique features, not waste it on stuff like event loops that can handle multi-socket communications and interface events without one thing locking up the other.

That's what prompted the development of Flux. Certain tasks and problems were popping up repeatedly in my work, and a generic remedy was in order. I started gathering the often-used parts in a glue library, and called it, yes, Flux. Also, some code which was strictly not glue, such as the IRC interface layer, found its way into the lib.

Goals

  • Simplify tasks. Provide simplified APIs to solve many common programmatical problems, while keeping more advanced functions available in API layers of increasing complexity.

  • Homogenize interfaces. Unify operations which are functionally similar and access exceptions through optional calls. Example: network sockets and interprocess pipes, which are both streams that can be buffered, waited for, etc. Here, the exceptions arise in the way the streams are established.

  • Homogenize platforms. Provide an environment that can be used to access OS funcions whose implementations differ from system to system, homogenously. Target platforms are as many Unix flavours as possible and, through Cygwin, Windows.

Assumptions

  • Application developers mostly use a small subset of the functionality in each full-blown library they link with. Example: A few selected algorithms from a crypto library providing tons.

  • Application developers want to link with as few libraries as possible. Example: Largish GNOME-based applications (this isn't as much work as you'd expect anymore, though, thanks to the gnome-config script).
Thus, Flux tries to span quite a large set of applications without providing extremely deep support for them. The idea is that you can survive using only one scheme for symmetric crypto, one for asymmetric crypto, etc. In this example, Flux will provide a few selected, well-known and strong algorithms - namely, the ones most likely to be useful. (Crypto isn't scheduled for implementation before 0.4.0, though). Read the plans for more information.