doc/RELEASE_NOTES.txt

   1 Release notes for OpenSRF 2.4.0
   2 ===============================
   3
   4 Supported platforms
   5 -------------------
   6 The following Linux distributions are supported:
   7
   8   * Debian 6 (Squeeze), 7 (Wheezy), and 8 (Jessie)
   9   * Fedora 17, 18
  10   * Ubuntu 12.04 LTS (Precise Pangolin) and 14.04 (Trusty Tahr)
  11
  12 New features in 2.4.0
  13 ---------------------
  14
  15 WebSockets support (LP#1268619)
  16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  17 WebSockets are a standards-compliant, cross-browser mechanism to support
  18 streaming, bi-directional communication between the browser and the
  19 server. For more information, see http://en.wikipedia.org/wiki/WebSocket
  20
  21 OpenSRF now offers a WebSockets gateway via an Apache plugin
  22 as well as updates to the OpenSRF JavaScript client library to
  23 support WebSockets as a transport.
  24
  25 To install the WebSockets gateway, follow the instructions
  26 in `README.websockets`.  By default, the WebSockets gateway
  27 listens on ports 7680 and 7682 and uses a separate Apache
  28 instance.
  29
  30 Cross Origin Resource Sharing for OpenSRF (LP#1002028)
  31 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  32 Browsers' same-origin policy currently restricts requests to the current
  33 website's domain to prevent various nefarious scenarios. However,
  34 because APIs and other web resources need to remain open to cross-site
  35 use, Cross Origin Resource Sharing (CORS) was created to allow services
  36 to formally authorize cross-origin requests. CORS makes it simple to use
  37 OpenSRF's HTTP translator and gateway APIs on websites using separate
  38 domains.
  39
  40 A couple examples of scenarios where this would be useful:
  41
  42 . A library would like an AJAX-driven "quicksearch" box on their main
  43   site, which is hosted on a different domain than their catalog.
  44 . A developer wants to create new web applications and services that
  45   tie into Evergreen, but does not wish to install Evergreen locally or
  46   configure a proxy.
  47
  48 Domains that are allowed to send cross-origin requests can now be
  49 specified in `opensrf_core.xml` as `cross_origin/origin` elements
  50 in the `gateway` element (full XPath `/config/gateway/cross_origin/origin`).
  51
  52 Note that the OpenSRF Javascript client library (`opensrf.js`) currently
  53 defaults to the root of the current web host (`/osrf-http-translator`).
  54 In addition, synchronous requests are presumed in some situations,
  55 resulting in the oncomplete method never returning (as blocking requests
  56 are not possible with cross-domain XHR).
  57
  58 Support for log tagging (LP#1343578)
  59 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  60 It is now possible to specify a log tag, i.e., a string to append
  61 to the application name in syslog message.  This allows easy filtering
  62 of log entries when running multiple OpenSRF instances on the same
  63 server.
  64
  65 Log tags can be set by adding `logtag` elements in `opensrf_core.xml`.
  66
  67 Enhancements in 2.4.0
  68 ---------------------
  69
  70 JavaScript library now uses browser-native JSON routines (LP#1316245)
  71 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  72 The routines `JSON2js` and `js2JSON` now use native browser JSON
  73 routines.  In addition, `jsonPretty` is removed in favor of
  74 `JSON.stringify`.
  75
  76 Users of the OpenSRF JavaScript library should note that as a
  77 consequence of this change, `JSON2js` will now throw an exception
  78 if it is given input not is not a valid JSON string.
  79
  80 Listeners now log and drop XMPP error messages (LP#1341687)
  81 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  82 The most common form of XMPP error messages are "bounced" messages, i.e.
  83 those where the recipient is not available.  Instead of passing these
  84 useless and confusing messages down to a drone for processing, listeners
  85 now log the error and drop the message.
  86
  87 An example of when this can occur is when a service is starting up and
  88 attempts to register with a router that is not yet available.
  89
  90 Removes osrf_ctl.sh (LP#1286248)
  91 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  92 The control script `osrf_ctl.sh` is removed in favor of `osrf_control`,
  93 which was introduced in OpenSRF 2.3.0.
  94
  95 Improved docgen output(LP#1292214)
  96 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  97 Docgen output now respects formatting present in method description.
  98
  99 Other enhancements
 100 ~~~~~~~~~~~~~~~~~~
 101   * Add support for Debian Jessie (LP#1306044)
 102   * Add support for Ubuntu Trusty (and removes support for Lucid) (LP#1315525)
 103   * Remove deprecated Jabber registration script (LP#1306044)
 104   * Improve const-correctness of osrfCachePutString and osrfCachePutObject (LP#1234816)
 105   * Document that perl2JSON doesn't order hash keys (LP#1285915)
 106   * Reorder changes to ejabberd.cfg in the install instructions
 107
 108 Bugfixes in 2.4.0
 109 -----------------
 110
 111 OpenSRF.pm no longer supplies AUTOLOAD (LP#1179660)
 112 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 113 Instead of simply producing an error message in the OpenSRF logs, calls
 114 to nonexistent subroutines are now fatal errors which will stop code
 115 execution.
 116
 117 `osrf_control` only affects processed owned by current user LP#1337401
 118 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 119 As of 2.3.0, OpenSRF can readily support running multiple instances on
 120 one server. This bugfix ensures that `osrf_control` only affects OpenSRF
 121 processes owened by the current user.