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

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

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) 2014 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:
