sox_ng wiki - Architecture


Architecture

SoX_ng is about building a mechanism for making regular releases of SoX using exiting work. Its primary target is the maintainers of sox packages in software distributions and incidentally and indirectly the developera and users of SoX.

Terminology

The kind of software we’re working on

As “packaged software”, similar to a software tool where the software is audio data, SoX is a “Mission-Critical System” for which spiral development and staged or evolutionary delivery are most effective.

Problem Definition

SoX has not had a release in the nine years since Chris Bagwell’s last release in 2015. The sole maintainer since then has done some good work resolving bugs but now seems to do more harm than good. Neither he nor the only other person with admin rights on 'sox.sf.net` will relinquish control of it, and the 37,000 downloads a week and the Donate button that pays into the maintainer’s personal PayPal account may be an influence on this position.

The distros that package SoX all have a different slew of patches to fix CVEs and other bugs; others package a recent snapshot from the git tree which has more bugs than the last release. See Testing.

Development work on SoX has fragmented. There are hundreds of forks on github, dozens of bug fixes and improvements with patches in the sox.sf.net issue tracker, all ignored. Most of the active and best developers have gone away to work on other things, to work on their own copies of SoX or to raise a family.

The objective of SoX_ng is to remedy this situation so that:

A second objective is to clarify and regularize SoX’s copyright position.

Program Organization

Major Classes

It’s not clear what this means for sox_ng.

Data Design

Business Rules

User Interface Design

Resource Management

The only finite resource is my time, scheduled in two-monthly batches for the micro and minor releases. A major release may be considered.

Security

The user sox_ng is registered on various platforms controlled by the email address sox_ng@proton.me. That should become sox_ng@fastmail.com

The passwords for the sox_ng accounts are currently held by Martin Guy and, where necessary, the phone number for SMSes and a legal address are those of Martin Guy.

Performance and Scalability

Done by the hosting platforms.

Interoperability

sox_ng’s data need to be shared with

Internationalization/Localization

Input/Output errors

It’s not clear what this means for sox_ng.

Fault Tolerance

Hosting platform downtime and malfunctions can be guarded against by

Error Processing

Architectural Feasibility

A time-based release schedule means that each release addresses issues resolved in time for its date.

At present there is a single point of failure, the sole SoX_ng maintainer, to be addressed by having more than one holder of sox_ng’s accounts' keys.

Overengineering

Each of the data components should have two instances:

Buy vs. Build

The web platforms are provided gratis and sox_ng cannot afford to pay anyone to performs its tasks.

Reuse

For its first releases it reuses existing work:

Code

Issues

Patches

It would be useful to have automatic notification of new commits to sox’s forks and new or updated issues in distros' trackers.

Change Strategy

Changes to sox_ng can be proposed on the mailing lists and acted on (or not) by the release manager.


Generated by makehtml.sh on Tue Apr 8 01:17:55 CEST 2025