-
Notifications
You must be signed in to change notification settings - Fork 0
Home
DRAFT -- Not even close to ready! 2015-12-18
A batch processing subsystem that is
- Easy for any user to submit and manage jobs
- Jobs that are restartable
- Light on system resources - small footprint, low CPU overhead
- Distributable - locally or worldwide
- Secure - uses the Unix permissions model
- Simple! In code and for the user
This project originated from the embedded systems world, and that will remain in scope. But the server and desktop world is also a big user base for it. So... this is a batch processing subsystem for:
- modern Linux distro's
- embedded systems running a modern eLinux
- command line users
- application programmers
- places needing minimal dependencies
The Linux distros targeted are RedHat- or Debian-based ones, such as RHEL, CentOS, Ubuntu, Mint, and so on; I arbitrarily picked 2012 as the dividing line (OK, not so arbitrary - the release of the 3.0 kernel). Other modern distros will probably work, I just don't have the test environments for them (hint hint - contribute here!)
I've started with a full set of command line utilities to manage queues and jobs. Those will be the primary interface into the system.
Application programmers would link against libjob; so the library and documentation for the API are part of this. It's currently C++, so I think we'd want a set of C-wrappers for the public API. (another hint!)
A very important part of this project is to keep dependencies to a minimum. It should work on a "bare" distro. A guiding rule is to not use anything you don't find in man 2, man 3, or the C and C++ standard libraries (and old ones at that!).
- Any non-Linux operating system: No windows, no iOS, not even HPUX. (Maybe BSD UNIX?) The guiding principle is if you need to conditionalize the code for it, then it's out of scope!
- No GUI, no Web UIs (but see also the job-rest project to provide
- No database engine in the traditional sense. Although the design loosely aligns with an MVC pattern, the "model" is the file system. I actually prefer a design that would easily allow using a database as the model, but the actual work to bring in some database is out of scope.
This isn't a playground to try out the newest design pattern you discovered; the design and coding are rather old-school -- proven, traditional methods that produce tight, solid, provable code, for just what is needed. This is system programming, not application programming; resources are limited and it's A Good Thing(tm)(R) to save 1k of memory with an implementation choice! But I also discourage being over-clever: yes, we all know you can swap two variables with xor's, but just use a temporary!
I'm still not ready to upload the source, but as a teaser, check out the man pages in this wiki.
TBS
TBS
-- Uncle Spook