Redvant

Purpose

The primary purpose of the Redvant moniker is to name the separation of some product lines from their domain space aspects. Products developed under its rubric can be compiled for operation strictly on the basis of the FOSS or COTS software upon which they are based without any integration with DS though in some cases this can gut the app if presentation of a DS feature was its purpose. A non-DS application can then supply a new purpose. My tl;dr line and other apps sold on stores may thus have core function repurposed to such new apps without committing to DS ops.

However this separation is only in evidence at the time of it's application in such non DS development activity. Redvant exposition is largely or entirely in terms of its use in domain space and does not further comment on this separability .

Précis

Redvant , or 'dcms<' (dcms-bra), is a collective term for software including react and servant within a DCP context and packaged as a reusable resource demonstrated in various applications such as the tl:dr and by the KEE.

"red" could be

react, redis, light in the ~700 nm range, a proper name as in red5, the parfume, riding hood, Malcom X, Simply, etc..

and "vant" is just from haskell-servant.

Use of Apache ISIS or other fat DDD pkg is intended later in our overall DDD product line engineering (as 'redvantis'). Some enterprise users may prefer the java basing of ISIS or an ERP core and this is anticipated for later development.

Requirements

At this time, this § is the sole exposition besides the code of any forks of constituent 3rd party packages in my public github or my original ones in my private git repo.

For pragmatic reasons, it is accounting oriented and doesn't address the full actual scope of use as implied by § 2.2 below, which could be confusing.

Later, there will coverage in the Docs DCMS volume.

Scope

Redvant carries our use of react and related node based stuff generally but here is discussed for the core purpose of transacting and accounting in domain space systems and apps. The transctional UI is actually django templating which could also be confusing.

As such it is deeply integrated with DCMS, DCP, etc. but these interfaces shall not be required in the product and its operation without them is a design requirement.

Design by Doing

The model use cases are the Web KEE SPA and the Ft doorbell, as well as GT2 2.1 and later and the tl:dr product line, in sofar as their front and middle are concerned.

Transacting

§ deleted see history.

Accounting

§ deleted see history.

Sonstiges

Commonalities

The same boat small form factor common reusable base with ...

1. DS SSO, messaging, and DCMS API setup for product families.
2. Videotelephony, defaults to Jitsi.

Deliverables

• tl;dr product line engineering cases for GT2, TASKPM, and YAS3FS.
• stable production level Ft and AC SPAs