gzochid NEWS -- history of user-visible changes
Copyright (C) 2020 Julian Graham
See the end of copying conditions.

Send comments, questions, and bug reports to gzochi-devel@nongnu.org

Changes in 0.13 (since 0.12):

* Bug fixes

** application nodes who submit uncommitable transactions should be disconnected
** Memory corruption in meta server on disconnect
** dataclient storage engine should release all locks on disconnect
** (gzochi client) does not quite work on OS X

* Incompatible changes

** Transactional storage interfaces return `unsigned char *'

As a side-effect of some of the changes described below, the `transaction_get'
and `transaction_get_for_update' functions of the storage engine interface
now return `unsigned char *' instead of `char *'; and the `transaction_put'
function now accepts `unsigned char *' instead of `char *' as the value to
store. This change should only affect implementors of the storage engine SPI;
depending on your compiler you may need to add some casts.

* Notable changes

** Support for Guile 3.0.x

The gzochid container can now be built using GNU Guile 3.0.x as its Scheme
platform, bringing considerable performance benefits to hosted game
applications. Released earlier this year, Guile 3.0.x features Just-In-Time
(JIT) generation of native code from Scheme programs, among other
optimizations relevant to authors of gzochid game applications. See the release
notes for Guile 3.0.0 for more information:
https://www.gnu.org/software/guile/news/gnu-guile-300-released.html.

Support for the Guile 2.2.x and 2.0.x series of releases (which are parallel-
installable with the 3.0.x series) is preserved, including support for reading
persisted game state from gzochid instances running different major versions of
Guile. (The in-memory representation of records changed between Guile 2.2.x and
3.0.x.)

** Support for MacOS / Clang

gzochid and gzochi-metad can now be built with Clang and run on recent versions
of MacOS.

** Enhanced support for containerized gzochid and gzochi-metad

Both gzochid and gzochi-metad now handle SIGTERM correctly, such that they will
attempt a clean shutdown of all services on receipt of a termination signal. In
turn, this change makes it easier to shut down and restart server processes
running inside Docker container instances. (Docker uses SIGTERM to gracefully
stop the root process in a container.)

See the Dockerfile.alpine image descriptor in the `contrib' folder in the root
of the distribution for an example of running a containerized gzochid.

** Per-application logging configuration

The logging behavior of the gzochid container can now be customized on a
per-application basis, such that different applications can have different log
message priority thresholds and even write messages to separate log file. See
"Transactional logging" in the gzochid manual for more information.


Changes in 0.12 (since 0.11.1):

* Bug fixes

** Application context new / free are not symmetric
** gzochi:managed-hash-table creates too many objects

* Changes to the distribution

** Texinfo manual for gzochi-metad 

An administrator's guide for gzochi-metad, the gzochi meta server, is now
available as part of the `gzochi-server' source distribution. It builds
automatically alongside the existing man pages and the gzochid Texinfo manual.

* Incompatible changes

** Object-efficient implementations of scalable data structures

The scalable data structures `gzochi:managed-vector' and
`gzochi:managed-hash-table' have been substantially rewritten to reduce the
number of structural elements they generate, improving transaction throughput
and reducing the size of transactional changesets.

As a result, the serialized form of these data structures has changed and is
not compatible with serialized instances created in previous releases. Migrating
a store created by a previous release is possible, but not automatic; email
"gzochi-devel@nongnu.org" if you need help.

* Notable changes

** Distributed task assignment via gzochi-metad

The meta server now tracks the node assignments for durable tasks and will
ensure that any task assigned to a gzochid container node that fails is assigned
elsewhere to complete. Task cancellations are now correctly routed across the
cluster in cases when the node requesting the cancellation is not the node to
which the target task is assigned. gzochid container nodes now use the meta
server to coordinate the execution of the initialization callback and the
resubmission of durable tasks on application startup to ensure that these
processes happen exactly once. Information about task assignments and task
throughput has been added to the admin web console in both gzochid and
gzochi-metad.

This implementation completes the set of services necessary to distribute a
gzochi game application across the cluster without modification, making it
fault-tolerant and enabling it to scale horizontally and take advantage of new
hardware as it is added.

** Support for large changesets in the distributed storage engine

Because of some technical limitations in the protocol used for communication
between the gzochid container and the meta server, it was previously impossible
to transmit the changeset associated with a transaction to the meta server for
persistence if the changeset was larger than 64k in size. Large changesets
should generally be avoided (since they correspond to larger - and thus less
concurrent - transactions) but they can be convenient for bootstrapping large
segments of game state - for instance, during a game's `initialize' callback.

The meta protocol now allows a gzochid container to spread the contents of
a changeset across multiple messages, while still ensuring that it is committed
atomically and consistently.

** New Scheme API: `gzochi:serialization-reference' and `g:<->'

To make it easier to support cases in which the serialization for an object must
itself be serialized - such as when an object is stored in a collection type
like a vector or hash table - a new type has been added to the Scheme API.
`gzochi:serialization-reference' is a subtype of `gzochi:serialization' that
holds a serializable reference to a module-qualified function.

The new Scheme syntax `g:<->' expands to the construction of a new
`gzochi:serialization-reference' record, optionally detecting the module in
which a serializer or deserializer procedure is defined.

** New Scheme serialization API: `gzochi:make-uniform-vector-serialization'

A new `gzochi:serialization' implementation has been added to make it easier
to include uniform vector fields on managed objects.



Changes in 0.11.1 (since 0.11):

* Bug fixes

** Guile version detection should fall back from 2.2 to 2.0
** Bad cast from 32-bit to 64-bit int type in `GzochidDataEvent' constructor
** `test-session' and `test-storage-dataclient' fail non-deterministically


Changes in 0.11 (since 0.10.1):

* Changes to the distribution

** Protocol dissectors for client-server and server-server protocols

A pair of Wireshark protocol dissectors in Lua, one for the "game" protocol
(used for client-application server communication) and one for the "meta"
protocol (used for application server-meta server communication) are now
included in the distribution, and can be used for debugging and auditing. See
the `README' file in the `contrib' folder for more information.

* Notable changes

** Better application server status reporting in meta server admin console

The admin web console for the gzochi meta server now lists all connected
application server nodes, and links to their respective admin web consoles, if
available.

Likewise, if the meta server is running an admin web console, a link to it will
appear in the web console for any connected application server nodes, allowing
the cluster to be traversed via web browser.

** Thread cleanup and documentation of gzochid thread pools

The gzochid container now runs fewer threads: 3 threads are required for the
base container services, plus the threads in the game task execution thread pool
(and their accompanying Guile GC threads). The `thread_pool.max_threads'
setting, which controls the size of this pool, is now documented in the
`gzochid.comf' file, as well as in the gzochid reference manual.

** Cooperative lock release for distributed storage engine

Building upon the initial implementation of the distributed data storage engine
in the most recent minor release, the storage engine now operates using a
cooperative lock release algorithm, such that locks on individual objects and
ranges of keys are seized by an application server node for a configurable
period of time and then released once this period expires and all active
transactions using a given lock have completed. Consequently, access to
application data is now shared by all nodes in the cluster.

** Distributed message delivery for sessions and channels

The container services behind the `session' and `channel' abstractions now
behave correctly in a multi-node server cluster, relaying messages through the
meta server as necessary, such that game application code doesn't need to be
aware of the location of client sessions for message recipients or the
distribution of channel membership across the cluster to be able to send
messages to them.

** More and finer-grained logging

Many more log statements have been added throughout gzochid and gzochi-metad,
especially at the `DEBUG' level and below, and many system components have been
partitioned by GLib log domain, adding a great deal more precision to the log
system.

There is a new log level (`TRACE') for extremely detailed logs about operations
on individual keys, messages, client events, etc.

To "turn up" the logging for gzochid or gzochi-metad, use the
`priority.threshold' option in the configuration file, or set the
`G_MESSAGES_DEBUG' environment variable appropriately.

* Bug fixes

** Intermittent failure of `test-storage-dataclient'.
** gzochid admin console should hide store browser in distributed mode
** valgrind warning during mem store delete: Use of uninitialized value
** In distributed mode, the dataclient storage engine gives inconsistent resp.


Changes in 0.10.1 (since 0.10):

* Bug fixes

** Warnings and test failures during i686 `make distcheck'


Changes in 0.10 (since 0.9):

* Changes to the distribution

** gzochi-metad, the gzochi meta server

The default build in the `gzochi-server' folder now produces a new executable:
gzochi-metad, a daemon service that supports a highly available cluster of
gzochid container servers. See the `README.gzochi-metad' file for provisional
documentation.

** GNU MP no longer required

The GNU Multiple Precision Arithmetic Library is no longer a first-order,
compile-time dependency of `gzochid'. (There is still, however, a transitive
runtime dependency on it via GNU Guile.)

** GNU GObject required

`gzochid' and `gzochi-metad' have compile-time and runtime dependencies on the
GObject module of GNU GLib. 

* Incompatible changes

** Object id and channel serialization format changes

As a side effect of several performance enhancements to the gzochid container's
data services, game objects written to the container's store are now identified
by a fixed-width byte key, as opposed to a variable-width hexadecimal string
key. The internal representation of the `gzochi:channel' structure has also
changed in a backwards-incompatible way. Consequently, application data stores
created by a previous release of the container are not compatible with version
0.10.

Migrating a store created by a previous release is possible, but not
automatically so with the toolchain bundled with this source distribution; email
"gzochi-devel@nongnu.org" for help.

** LMDB and upscaledb (hamsterdb) no longer supported

Neither LMDB nor upscaledb has a lock strategy that supports truly interleaved,
concurrent transactions. The corresponding storage engine modules have been
removed from the distribution.

** Non-transactional functions removed from storage engine SPI

The non-transactional / single-operation variants of the "get," "put," etc.
operator fields have been removed from the `gzochid_storage_engine_interface'
struct.

* Notable changes

** Improved transaction throughput and concurrency against mem store

The built-in, memory-backed transactional store introduced in version 0.8 now
groups individual key-value records into 4k pages, similar to the B+tree
implementation in Berkeley DB and other key-value databases. As a result, the
potential for deadlock in several common gzochid persistence workloads (such as
durable task scheduling) is greatly reduced.

** Reduced lock contention on several key code paths

In addition to the storage-level enhancements described above, the lock
acquisition order for disconnected session handling and for the
`gzochi:removing-binding' operation have been optimized to avoid contention with
simultaneously executing transactions.

** Lower average latency for client message processing

Processing of client messages was previously being serialized on the I/O main
loop thread. Messages are now dispatched to the task queue's thread pool for
asynchronous execution, yielding a throughput improvement proportional to the
size of that pool.

* Bug fixes

** Sporadic SIGSEGV during deletes against mem storage manager
** Sporadic test failure: /storage-mem/tx/deadlock/simple
** Guile modules installed to incorrect location.
** Channel side effects lack proper transaction semantics


Changes in 0.9 (since 0.8):

* Changes to the distribution

** Benchmark suite

The new `benchmarks' folder at the top level of the `gzochi-server' source 
distribution includes scripts and application code for running and reporting on
the performance of different gzochi application workloads. The first such
benchmark ("echo chamber") exercises the channel messaging subsystem and
reports on client message round trip times.

See the README files in the `benchmarks/echo-chamber' subfolder for instructions
for running the benchmark.

* Incompatible changes

** Server configuration setting name changes

The documentation and implementation for previous releases disagreed on the
names of several settings in the server configuration file. As part of
correcting those inconsistencies, the following configuration settings have been
renamed from:

 - "server.auth.plugin.dir" to "auth.plugin.dir"
 - "server.storage.engine" to "storage.engine"
 - "server.storage.engine.dir" to "storage.engine.dir" 

* Notable changes

** Exit on bootstrap failure

The gzochid container will now exit immediately if any of its necessary startup
operations fail. These operations include bootstrapping the Scheme API and
creating the work and application deployment folders on the local filesystem.

** New application statistics

The internal statistics capture module now publishes the aggregate number of
messages sent and received, via the administrative web interface.

* Bug fixes

** Non-retryable condition in disconnect handler causes abort
** Double-free during disconnected session cleanup

In addition to the above, this release incldues fixes for several dozen memory
leaks and other issues affecting container stability. The server is now a great
deal better behaved in terms of its memory allocation and book-keeping
behavior. 


Changes in 0.8 (since 0.7):

* Changes to the distribution

** Storage engines build as modules

The data storage subsystem in gzochid chooses the storage engine to use at boot
time. Storage engines are now built (and loaded) as dynamic modules - installed 
independently from the server - which allows multiple engines to be enabled at 
the time `configure' is run. The storage engine interface is now installed as a
header file (`gzochid-storage.h') under the installation prefix, to make it 
available for custom implementations. See "The server configuration file" in the
manual for more information on storage engine selection.

** GNU Serveez no longer required

The server's dependency on libserveez has been removed; the server now includes
a socket server based on GLib's IO channels and main loop functionality.

** Pre-installation environment

The new `meta' folder at the top level of the `gzochi-server' source 
distribution includes a set of scripts that make it easier to launch the gzochid
server and the database management tools after running `make' but before running
`make install'.

* Notable changes

** New storage engine: Memory

Experimental support for a new storage engine based on an in-memory B*-tree has
been added. Unlike the durable, third-party storage engines, which are now built
as dynamic modules, the memory storage engine is compiled directly into gzochid,
and is always available. This storage engine does not persist anything to disk,
and thus is not safe for use in a production environment; it is intended 
primarily as a failsafe or quick-start option. (In the future, it may have 
additional uses!)

** New configuration options

Some options previously configurable only at build time are now exposed by
gzochid.conf, the server configuration file: `auth.plugin.dir', 
`storage.engine', `storage.engine.dir'. See commentary in `gzochid.conf' and 
"The server configuration file" in the manual for more information on these
settings and their default values.

** External transactions

Transactions coordinated by the gzochid container on behalf of a gzochi game 
application can now be integrated with external transaction-aware processes, 
such as relational databases. This functionality is exposed via the 
`(gzochi tx)' SPI. An example application that demonstrates a simple case of an
integration of an external transaction via Guile DBI has been added to the 
distribution. See "External transactions" in the manual for more information on
external transaction participants.

** New application lifecycle event

gzochid applications can define a callback handler for a new event (`ready') to
be called whenever the application is launched by the gzochid container -
effectively, a variant of the `initialized' event that is fired whenever the
server starts.

** New application statistics

The internal statistics capture module now publishes the following aggregates
via the administrative web interface: Average, minimum, and maximum transaction
duration.

* Bug fixes

** Conditions raised from debugging context lose their stack context


Changes in 0.7 (since 0.6):

* Incompatible changes

** Client session library renamed

To avoid conflicts with the new `(gzochi client)' reference client library, the
client session library in the gzochi server API has been renamed to 
`(gzochi session)'. Any direct imports of this library in game application code
should be updated to reflect this change. Application code that imports the
`(gzochi)' aggregation library is unaffected.

** Managed records no longer automatically nongenerative

The server's type management system has been rewritten to allow greater
flexibility in type resolution. One consequence of this change is that managed 
records are no longer automatically nongenerative in the R^RS sense; the 
gzochid type system has alternate means of uniquely distinguishing managed 
record types. Any application code that relies on the implicit nongenerativity
of managed record types should be updated (or at least recompiled). See
"Managed records" in the manual for more information on type resolution.

* Notable changes

** New data management tools

The build process for the gzochid server now produces three additional binaries:
`gzochi-dump', `gzochi-load', and `gzochi-migrate'. These tools allow you to 
portably export, import, and transform the data in your game application 
databases, across server installations and storage engines. See "Database tools"
in the manual for more information.

** Use an alternate server configuration file at runtime

An alternate path to gzochid.conf, the server configuration file, may now be
specified on the command line for gzochid and the database tools mentioned above
via the `-c' or `--config' arguments.

** Warnings for possible serialization problems

The server now logs a warning when the deserialization process for a managed
record fails to consume all of the data persisted for that record in the 
database, as this may be a sign of data corruption or a problem with with
serialization.

* Bug fixes

** Server crash on missing gzochid.conf file
** Deserialization failures can cause an assertion failure and core dump
** Assertion failure from BDB on transaction timeout


Changes in 0.6 (since 0.5):

* Notable changes

** New storage engines

Experimental support for two new storage engines has been added: hamsterdb and
Symas Lightning (LMDB). These databases provide the same transactional 
guarantees as BerkeleyDB and may be an attractive alternative for users who wish
to avoid linking with libdb. Support for these engines may be enabled by running
`configure' with the arguments `--with-storage-engine=hdb' and 
`--with-storage-engine=lmdb', respectively.

** Swept connections are fully disconnected on startup

In addition to freeing the resources related to severed client connections on a
restart of the server, the gzochid container now also invokes the registered
session disconnect handler (if any) for each swept client session. The hope is
that this behavior will help preserve continuity of game state across restarts
of the container.

** Memory leak cleanup

Twelve major sources of memory leaks have been identified and fixed in this 
release, leading to a more stable server process with a lower overall memory 
footprint.

* New interfaces

** Syntactic callback creation

A more concise mechanism for constructing task and session lifecycle callbacks
has been added. The `g:@' syntax (inspired by Guile's `@' form) expands to an
invocaftion of `gzochi:make-callback' with the specified procedure and 
optionally associated data. See "(gzochi app)" in the manual for more 
information.

* Bug fixes

** Transactional logging functions incorrectly named in documentation


Changes in 0.5 (since 0.4):

* Notable changes

** Remove GDBM-based storage engine

The GDBM-based storage engine, which was deprecated in an earlier release, has
been removed. As such, the only valid argument to the `--with-storage-engine'
flag in `configure' is `bdb'.

** &gzochi:object-removed is non-fatal

Attempting to dereference a managed reference that has been removed (such as 
the handle for a canceled periodic task, or a disconnected client session) is
no longer fatal to the current transaction. Application code can thus recover
from a `&gzochi:obect-removed' condition by preventing a non-local exit (by 
using a `guard' expression, for example).

** Performance improvements

Several performance enhancements have been made. Among them: Nagle's algorithm 
is now disabled for all game socket connections, and repeated mutation of the 
same object in a single transaction no longer triggers a round trip to the 
storage engine.

** Additional application statistics

The average transaction duration for running game applications is now computed
and displayed on the embedded web console.

* New interfaces

** Managed sequences

A new managed data structure has been added to the data module of the gzochi 
Scheme library, to enable the storage of an unbounded number of 
sequentially-ordered elements: `gzochi:managed-sequence'. Its implementation is
based on the Java ScalableList data type from Project RedDward, and its API is 
modeled on that of the SRFI-44 sequence type. See "(gzochi data)" in the manual
for more information on the `gzochi:managed-sequence' type.

* Bug fixes

** Disconnected clients should be swept immediately
** Resubmitted tasks don't resolve callback procedures properly


Changes in 0.4 (since 0.3):

* Notable changes

** Periodic task scheduling

Application tasks can now be scheduled to repeat on a configurable period,
without the need for explicit resubmission. This rescheduling behavior is
durable, such that a task scheduled to repeat periodically will automatically
continue to do so following a server restart.

** Pluggable authentication

The user authentication system in the gzochid container has been restructured
to support multiple methods of authentication, instead of just the fake 
"pass-thru" mechanism provided in previous releases. And there are now two 
additional ways to authenticate users of an application: Against a "password 
file" of usernames and passwords; or using Kerberos 5. See "User 
authentication" in the manual for the details of how authentication plugins are
loaded and for a description of the behavior of the new authentication plugins 
included in this release.

** Application statistics

Some simple metrics are now collected about the behavior of running game 
applications: The numbers of successful and failed transactions, the numbers of
bytes read from and written the to game data store. The embedded web console 
now reports on these metrics for each running application.

* New interfaces

** gzochi:task-handle and gzochi:cancel-task

The contract of `gzochi:schedule-task' has been extended to support periodic
task scheduling. Consequently, when a task is schedule to repeat on a specified
period, a task handle is returned to the caller. Task handles are managed 
records that can be stored in user-defined data structures and passed to other 
tasks or callbacks. In particular, a task handle may be given as the argument 
to `gzochi:cancel-task', which stops a periodic task from repeating further. 
See "(gzochi task)" in the manual for more information on task scheduling.

* Bug fixes

** gzochid configure script doesn't fail on missing Serveez
** Documentation: Clarify the install path of gzochid.conf


Changes in 0.3 (since 0.2):

* Notable changes

** Configurable transaction timeouts

When an application transaction's execution exceeds a configured timeout, it
will now be automatically marked for rollback (or prevented from committing), 
preventing slow or data-hungry tasks from bottlenecking application 
performance and task throughput. See "The server configuration file" in the
manual for more information on configuring this timeout.

** Transaction retry support

Application transactions that fail for transient reasons, such as exceeding the
timeout described above, will be automatically retried by the gzochid
transaction management system.

** Simpler declarations of managed record types

Two inconvenient aspects of declaring a new managed record type have been
eliminated in this release: Managed records no longer need to be made 
explicitly "nongenerative," as the type definition system will choose a stable
uid for the type automatically; and managed record "base" types (i.e., ones
without a "parent" clause) no longer need to invoke the empty base constructor 
from inside their protocol implementation, since the procedure passed to their
protocol will now be a field-binder.

** Dependency on GNU Serveez 0.2

Prior to this release, gzochid depended on a pre-release version of GNU Serveez
0.2, which was required for GNU Guile 2.x support. Since the release of gzochid
0.2, the Serveez team has created a formal 0.2 release, and the build files for
gzochid have been updated to reflect this. Grab the Serveez source code at
http://www.gnu.org/software/serveez/.

* New interfaces

** &gzochi:transaction-retry and &gzochi:transaction-timeout

Two new condition types related to the enhanced transaction support described
above have been added to the `(gzochi conditions)' library (and to the 
`(gzochi)' aggregation library). See "gzochi conditions" in the manual for more
information on these condition types and how the container raises and handles 
them.

* Bug fixes

** Channel manager should remove sessions that are found to be dead
** Managed record protocol delegation should hide managed record parenthood
** Non-local exit during serialization should trigger a rollback.
** SEGV when `logged-in' transaction fails
** Task delays not being respected
** Multiple applications cannot start at the same time


Changes in 0.2 (since 0.1):

* Notable changes

** Remote debugging for game applications

The gzochid container now offers a remote debugging interface. Using a telnet
client, a debugging user can connect to a running gzochid server instance and 
evaluate arbitrary Scheme expressions in the context of a specified game
application. See "Debugging" in the manual for more information.

** Support for alternative storage engines

The storage layer has been refactored in order to allow storage engines besides
GNU DBM to be selected at build time. The first new storage engine to be 
supported is BerkeleyDB. To use BerkeleyDB, pass the 
`--with-storage-engine=bdb' argument to `configure'. See "Installation" in the
manual for details about using a different storage engines.

** Transaction rollback detection

When a transaction on the `names' or `oids' store of a gzochi game application
is rolled back, the outer, application-level transaction is now correctly
marked for rollback as well. When an application invokes a function from the
gzochi API in a transaction that has been marked for rollback, a 
non-continuable condition is now raised.

** Logging enhancements

Log messages are now written to the server log in a synchronous way, such that
messages from different threads will no longer be interleaved on a single line.
A log priority threshold can also be set (via gzochid.conf) so that finer-
grained messages are excluded from the logs. See "Logging" in the manual for 
more information.

* New interfaces

** Administrative API

A new administrative API, primarily for use during debugging, is available from
the `(gzochi admin)' library. This release exports the 
`gzochi:application-context' type, and the functions `gzochi:applications', 
`gzochi:current-application', and `gzochi:with-application'. See "gzochi admin"
in the manual for more informaton.

** %gzochi:application-root

This new fluid stores the root deployment directory of the current application,
for the purposes of locating non-Scheme resources. See "Application deployment"
in the manual.

** Managed vectors

The `gzochi:managed-vector' type and its associated functions, which extend 
gzochi's transactional guarantees to operations over vectors of managed 
records, were present in the `(gzochi data)' library in version 0.1 but not 
documented and not exported from the `(gzochi)' aggregation library. A more 
flexible and more efficient implementation of this API has been provided in 
this release.

** Managed hashtables

A complete implementation has likewise been provided for 
`gzochi:managed-hashtable', based on the Java ScalableHashMap implementation in
RedDwarf Server. This type and its accompanying functions are exported from
`(gzochi data)' and from the `(gzochi)' aggregation library. See "Scalable data
structures" in the manual for more information about `gzochi:managed-hashtable'
and `gzochi:managed-vector'.

** Serialization for generic objects

A Scheme datum that is not a managd record can now be wrapped in an instance of
the new `gzochi:managed-serializable' type, which allows it to be serialized 
and persisted to a game's data store and to be included in a managed object
graph. `gzochi:managed-serializable' and its accompanying functions are 
exported from `(gzochi data)' and from the `(gzochi)' aggregation library.

** Extended API for managed records

The following functions are now available (as pass-thrus to their R6RS record
API counterparts) from the `(gzochi data)' and `(gzochi)' libraries:
`gzochi:managed-record-rtd', `gzochi:managed-record-type-name', 
`gzochi:managed-record-type-parent', `gzochi:managed-record-type-uid'.

* Bug fixes

** Deadlocks while processing channel operations
** `gzochi:remove-binding!' should not remove bound object.
** Transactions should roll back on a non-local exit from application code
** Extraneous forked processes are launched
** Sporadic data corruption during initialization
** Sporadic segmentation fault during initialized callback
** Userland bindings should be prefixed with "o."


Copyright information:

Copyright (C) 2017 Julian Graham

   Permission is granted to anyone to make or distribute verbatim copies
   of this document as received, in any medium, provided that the
   copyright notice and this permission notice are preserved,
   thus giving the recipient permission to redistribute in turn.

   Permission is granted to distribute modified versions
   of this document, or of portions of it,
   under the above conditions, provided also that they
   carry prominent notices stating who last changed them.


Local variables:
mode: outline
paragraph-separate: "[ 	]*$"
end:
