Apollo web services for coventry
 
 
 
 
 
 
Go to file
David Sugar 5d148b2f80 Update interface definition 2023-09-11 04:30:02 -04:00
.make Remove vet from golang.mk test 2023-07-15 11:17:47 -04:00
.vscode Editor exclusions 2023-05-20 10:14:05 -04:00
cmd/apollo Line password support 2023-09-09 13:38:17 -04:00
etc Initial checkin 2023-05-07 11:08:12 -04:00
lib Update interface definition 2023-09-11 04:30:02 -04:00
web Line password support 2023-09-09 13:38:17 -04:00
.gitattributes Initial checkin 2023-05-07 11:08:12 -04:00
.gitignore Further changes to main 2023-05-08 14:23:52 -04:00
.woodpecker.yml Initial checkin 2023-05-07 11:08:12 -04:00
CHANGELOG.md Prep for future release (0.1.1) 2023-09-09 15:12:35 -04:00
CONTRIBUTING.md Base public docs 2023-07-15 16:30:37 -04:00
LICENSE.md Initial checkin 2023-05-07 11:08:12 -04:00
Makefile Prep for future release (0.1.1) 2023-09-09 15:12:35 -04:00
README.md Base public docs 2023-07-15 16:30:37 -04:00
TODO.md Add logo branding, kill template extensions 2023-06-15 15:34:31 -04:00
go.mod Optional systemd support 2023-08-31 06:44:08 -04:00
go.sum Optional systemd support 2023-08-31 06:44:08 -04:00

README.md

What is Apollo?

Apollo offers a web administrative console and web integrated telephony services for a Coventry phone system. It is the point of network api contact, and provides additional client support services, such as rosters and dialing directories for coventry specific endpoints like partisipate. Apollo requires and suppliments an install of Coventry to be at all useful.

Installation

Make "install" is sufficient to install the Apollo integration server 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

Apollo 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/apollo/issues. When entering a new support issue, please mark it part of the support project. I also have dyfet@jabber.org. Apollo packaging build support for some GNU/Linux distributions may be found on https://pkg.gnutelephony.org/apollo. 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.