The Babylon project is a re-creation of many of my original PBX network integration tools from the early 1990's, in go.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
David Sugar dbb4a18149 Fix signal handler 1 week ago
.make Track last command update for idle time (#4) 1 month ago
cmd/f9600 Fix signal handler 1 week ago
etc Official config 2 weeks ago
lib Track last command update for idle time (#4) 1 month ago
test Initial checkin 4 months ago
.gitattributes Initial checkin 4 months ago
.gitignore Initial checkin 4 months ago
CHANGELOG.md Track last command update for idle time (#4) 1 month ago
CONTRIBUTING.md Initial checkin 4 months ago
LICENSE.md Initial checkin 4 months ago
Makefile Prep for next release (0.0.3) 2 weeks ago
README.md Initial checkin 4 months ago
TODO.md Initial checkin 4 months ago
go.mod Improved debug and release support (#3) 1 month ago
go.sum Initial checkin 4 months ago

README.md

What is Babylon?

The Babylon project is a re-creation of many of my original PBX network integration tools from the early 1990's, in go. Many of these were originally written in C for QNX, and then ported to Linux. This will eventually include the F9600 mml server, a Panasonic PAPI DBS server, an smdi server, the SPO256 speaker, cdr logging servers, a cdr collection server, and other odd things.

One reason for this project is simply to help me decide best practices for developing enterprise services in golang going forward. This project will eventually directly support building for traditional os packaging, offer ansible deployment, or docker creation, using a single top level Makefile.

Installation

Make "install" is sufficient to install these tools and daemons on a generic posix system. This installs to /usr/local by default, and can be overridden with a PREFIX setting, such as ''make PREFIX=/usr install''. The Makefile also makes it easy to cross-compile, as well as managing separate debug and release builds. It also should be easy to integrate with traditional OS packaging.

In git checkouts I manage a vendor directory outside of git. This is because it may generate different content when you update the go.mod file. Generating a vendor branch means it also can get into the stand-alone dist tarball, and that can then be used in network isolated build systems. Since the builds are cached anyway without a vendor directory, this has no impact on performance. The vendor directory is only refreshed if the go.sum file changes.

Participation

Babylon is written in Go. I use go modules support, so this project can be cloned into any stand-alone directory and built there. I also use a front-end Makefile to simplify builds and offer basic project automation.

My Makefile includes a "dist" target, which produces a stand-alone tarball that can then be used to build install the tools detached from the repo. This is particularly useful for OS packaging. I include a "lint", "test", and "coverage" target to test and verify code. The default make builds binaries in target/{build-type} in a manner like rust cargo does, where they can then be tested. Cross-compiling goes into target/${GOOS}-${GOARCH}. Many of these special targets are standardized in the .make directory.

Support

Support is offered thru https://git.gnutelephony.org/babylon/issues. When entering a new support issue, please mark it part of the support project. I also have dyfet@jabber.org. Babylon packaging build support for some GNU/Linux distributions may be found on https://pkg.gnutelephony.org/babylon. I also have my own build infrastructure for Alpine using ProduceIt, and I publish apk binary packages thru https://public.tychosoft.com/alpine. In the future maybe other means of support will become possible.