DKlann: Clean up and mark "completed" items.

2020-09-14T15:07:32Z

Clean up and mark "completed" items.

Higgles: Created page with "Rivendell is developed on a "two-track" system: a "stable" series of releases (currently numbered 1.x.x), which are well tested and generally reliable; and a "development" ser..."

2018-03-13T11:41:14Z

Created page with "Rivendell is developed on a "two-track" system: a "stable" series of releases (currently numbered 1.x.x), which are well tested and generally reliable; and a "development" ser..."

New page

Rivendell is developed on a "two-track" system: a "stable" series of releases (currently numbered 1.x.x), which are well tested and generally reliable; and a "development" series (currently only available as the head branch in Rivendell CVS) that is undergoing active development and may be in various states of testing and reliablility, including totally broken. Instructions for checking out copies of each from CVS can be found in [[Downloading Rivendell Source from CVS]].

=== Current Development Roadmap ===
This is a list of current enhancements slated to be worked on by the project developers for deployment in the upcoming Rivendell 2.x.x.

==== Qt 4 Support ====
The first order of business. The thinking at this point is that a basic port using the Qt3 compatibility library will be adequate, as removing that will require some very major reworking of large parts of the system.

==== Proper UniCode Support ====
No more (const char *)s! This will (possibly) also require tweaking charsets on MySQL to work properly. Another big job, as this will require recasting virtually every SQL statement in the codebase.

==== CAE Service Methods ====
Currently /var/snd/ needs to be writable to all Rivendell users. By modifying caed(8) to provide a set of audio import/export "services", eliminate this requirement, which is a big security hole. This would also make all the ugly import/export stuff in 'scripts/' go away.

==== Inter-Host/Module Event Notification ====
Some sort of inter-host and inter-module general update notification method is needed for cases where changes in one object/module can cause side effects in others (e.g. changing a cart in RDLibrary referenced by a running log in RDAirPlay). We currently brute-force this case by polling the DB for changes -- a big scalability bottleneck. The current thinking is to designate a privately-scoped multicast address for this (basically, similar to how RDCatch deck updates are now handled, but much more efficiently as we wouldn't need to maintain one-to-one connection states).

==== Proper Log Machine Abstraction ====
The log machine logic at present is tightly bound to GUI rendering code, making log machine operation with realtime permissions extremely problematic. The plan is to abstract the basic machine operation away from any presentation code (essentially, what we now do with RDCatch(1)/RDCatchd(8). This would also make it possible to develop multiple front ends for RDAirPlay (e.g. Ajax, Ncurses, etc).

==== Library Storage Formats ====
Adding FLAC support seems a natural choice. OggVorbis may be possible as well, but CPU requirements for encoding remain high even with current-generation CPUs. A generalized method of storing peak-value data will be needed, as the current method is dependent on the MS RIFF WAVE format, which is not definied for any of the open source encodings.

==== Surround-Sound Support ====
Both 5.1 and 5.1/2.0 (Fraunhofer's "HD Radio") modes.

==== Remote Operation ====
Operation from remote environments is a frequently requested feature, especially for Library managment and Voicetracking. Some general system infrastructure will be required (e.g. audio "thumbnails", low-bitrate renditions of content suitable for streaming over remote connections).

==== Improved Stream Management ====
At present a playback stream is obtained at load playback time and held until the playback is unloaded. Given that some ASI cards have as few as 4 available playback streams, it is not hard to run the system out of available playbacks when pausing a few files. We need to free streams on paused events.

My proposed fix is to retire 'unload playback' and to add a 'pause' rml instead. Thus a stopped playback is automatically unloaded and a loaded playback can be made to time out after a few minutes to avoid any chance of leaking playbacks. The pause state will release the stream (if these are limited resorces) while keeping the file open.

Further the return code for load playback should differentiate between no file, invalid file and no available stream so that rdairplay can avoid the death spiral if it does run out of streams.

@@ Line 1: / Line 1: @@
-Rivendell is developed on a "two-track" system: a "stable" series of releases (currently numbered 1.x.x), which are well tested and generally reliable; and a "development" series (currently only available as the head branch in Rivendell CVS) that is undergoing active development and may be in various states of testing and reliablility, including totally broken.  Instructions for checking out copies of each from CVS can be found in [[Downloading Rivendell Source from CVS]].
+'''Note''': This article is somewhat historical. Rivendell development is now (in 2020) guided by using the [https://github.com/ElvishArtisan/rivendell/issues Issues] page on GitHub. Feel free to post a bug report or a feature request there.
 === Current Development Roadmap ===
-This is a list of current enhancements slated to be worked on by the project developers for deployment in the upcoming Rivendell 2.x.x.
+This is a list of current enhancements slated to be worked on by the project developers for deployment in upcoming Rivendell releases.
-==== Qt 4 Support  ====
+As of Version 3.4.1 (and prior), the QT3 code has been removed. There exist some remaining use of QT3 in QT4's "''QT3 Compatibility Mode''".
-The first order of business.  The thinking at this point is that a basic port using the Qt3 compatibility library will be adequate, as removing that will require some very major reworking of large parts of the system.
-==== Proper UniCode Support  ====
+==== Proper UniCode Support (COMPLETE as of Version 3) ====
-No more (const char *)s!  This will (possibly) also require tweaking charsets on MySQL to work properly.  Another big job, as this will require recasting virtually every SQL statement in the codebase.
+No more (const char *)s!  This will (possibly) also require tweaking charsets on MySQL to work properly. Another big job, as this will require recasting virtually every SQL statement in the codebase.
-==== CAE Service Methods ====
+==== CAE Service Methods (COMPLETE) ====
-Currently /var/snd/ needs to be writable to all Rivendell users.  By modifying caed(8) to provide a set of audio import/export "services", eliminate this requirement, which is a big security hole.  This would also make all the ugly import/export stuff in 'scripts/' go away.
+Currently ''/var/snd/'' needs to be writable to all Rivendell users. By modifying caed(8) to provide a set of audio import/export "services", eliminate this requirement, which is a big security hole. This would also make all the ugly import/export stuff in ''scripts/'' go away.
-==== Inter-Host/Module Event Notification ====
+==== Inter-Host/Module Event Notification (COMPLETE) ====
-Some sort of inter-host and inter-module general update notification method is needed for cases where changes in one object/module can cause side effects in others (e.g. changing a cart in RDLibrary referenced by a running log in RDAirPlay).  We currently brute-force this case by polling the DB for changes -- a big scalability bottleneck.  The current thinking is to designate a privately-scoped multicast address for this (basically, similar to how RDCatch deck updates are now handled, but much more efficiently as we wouldn't need to maintain one-to-one connection states).
+Some sort of inter-host and inter-module general update notification method is needed for cases where changes in one object/module can cause side effects in others (e.g. changing a cart in RDLibrary referenced by a running log in RDAirPlay). We currently brute-force this case by polling the DB for changes -- a big scalability bottleneck. The current thinking is to designate a privately-scoped multicast address for this (basically, similar to how RDCatch deck updates are now handled, but much more efficiently as we wouldn't need to maintain one-to-one connection states).
-==== Proper Log Machine Abstraction ====
+==== Proper Log Machine Abstraction (COMPLETE as of Version 2.19) ====
-The log machine logic at present is tightly bound to GUI rendering code, making log machine operation with realtime permissions extremely problematic.  The plan is to abstract the basic machine operation away from any presentation code (essentially, what we now do with RDCatch(1)/RDCatchd(8).  This would also make it possible to develop multiple front ends for RDAirPlay (e.g. Ajax, Ncurses, etc).
+The log machine logic at present is tightly bound to GUI rendering code, making log machine operation with realtime permissions extremely problematic. The plan is to abstract the basic machine operation away from any presentation code (essentially, what we now do with RDCatch(1)/RDCatchd(8). This would also make it possible to develop multiple front ends for RDAirPlay (e.g. Ajax, Ncurses, etc).
 ==== Library Storage Formats ====
-Adding FLAC support seems a natural choice.  OggVorbis may be possible as well, but CPU requirements for encoding remain high even with current-generation CPUs.  A generalized method of storing peak-value data will be needed, as the current method is dependent on the MS RIFF WAVE format, which is not definied for any of the open source encodings.
+Adding FLAC support seems a natural choice. OggVorbis may be possible as well, but CPU requirements for encoding remain high even with current-generation CPUs. A generalized method of storing peak-value data will be needed, as the current method is dependent on the MS RIFF WAVE format, which is not definied for any of the open source encodings.
 ==== Surround-Sound Support ====
@@ Line 26: / Line 30: @@
 ==== Remote Operation ====
-Operation from remote environments is a frequently requested feature, especially for Library managment and Voicetracking.  Some general system infrastructure will be required (e.g. audio "thumbnails", low-bitrate renditions of content suitable for streaming over remote connections).
+Operation from remote environments is a frequently requested feature, especially for Library management and voice tracking. Some general system infrastructure will be required (e.g. audio "thumbnails", low-bitrate renditions of content suitable for streaming over remote connections).
-==== Improved Stream Management ====
+==== Improved Stream Management (COMPLETE?) ====
 At present a playback stream is obtained at load playback time and held until the playback is unloaded. Given that some ASI cards have as few as 4 available playback streams, it is not hard to run the system out of available playbacks when pausing a few files. We need to free streams on paused events.

Development direction of Rivendell - Revision history

DKlann: Clean up and mark "completed" items.

Higgles: Created page with "Rivendell is developed on a "two-track" system: a "stable" series of releases (currently numbered 1.x.x), which are well tested and generally reliable; and a "development" ser..."