Changes between Version 69 and Version 70 of ReleaseNotes


Ignore:
Timestamp:
26.08.2013 19:09:22 (8 years ago)
Author:
jri
Comment:

4.1.1 release notes, intro

Legend:

Unmodified
Added
Removed
Modified
  • ReleaseNotes

    v69 v70  
    66 
    77== ''upcoming:'' DeepaMehta 4.1.1 == 
     8 
     9While !DeepaMehta 4.1.1 has not much to offer for the end user it brings crucial bug fixes and various enhancements in the Plugin Development Framework. Main features of this release comprise timestamps (not yet user perceivable) and a new **Time API**, better **performance** through exploitation of the browser cache, and support for working collaboratively. Plugin developers can store, index, and retrieve arbitrary **topics/association metadata**. Numeric metadata is [[http://en.wikipedia.org/wiki/Trie|trie-indexed]] which make it suitable for time- and and geo-based range queries. 
     10 
     11You can update an existing !DeepaMehta 4.1 installation while keeping all your data or perform a !DeepaMehta 4.1.1 clean installation. 
    812 
    913New features: 
     
    1216* **Edit conflict detection** (#479). The server rejects a PUT request when the resource has changed meanwhile. The check is based on the resource's "last modified" timestamp. This fights the "lost update" problem when working collaboratively. Edit conflict detection is realized at HTTP level, that is a conditional PUT request (`If-Unmodified-Since` request header). Conflict ''resolution'' is not yet realized. 
    1317 
     18Plugin Development Framework: 
     19* A plugin can store **Node Properties**. Node properties are topic/association metadata like timestamps, ACL information, or geo coordinates. The new Property API can retrieve topics/associations based on property value or value range (#472). Node properties can be indexed. Numeric properties are trie-indexed which allows for performant range queries. Ranges are particularly useful for time-based or geo-based retrieval (#490). Property keys are namespaced (#491). 
     20* HTTP response generation: 
     21    * A plugin can produce specific HTTP (error) responses by throwing a WebApplicationException from its resource methods or event handlers (#484, #481). 
     22    * Exceptions thrown from resource methods or event handlers must no longer be wrapped in a WebApplicationException if a 500 response is intended (#484). 
     23* (REST) resource methods can use an arbitrary class for the entity parameter as long as the representation is JSON and the class has a public JSON constructor. Implementing a custom JAX-RS provider class is no longer required (#277). 
     24* 3 new Core Events: 
     25    * `SERVICE_REQUEST_FILTER` allows plugins to manipulate or interrupt REST service requests (#480). 
     26    * `RESOURCE_REQUEST_FILTER` allows plugins to manipulate or interrupt static resource requests (#480). 
     27    * `SERVICE_RESPONSE_FILTER` allows plugins to manipulate REST service responses, e.g. by setting certain response headers (#477). 
     28* Webclient: 
     29    * (Client-side) plugins can send REST service requests asynchronously (#476). 
     30    * New Webclient event (client-side): `pre_send_request` allows plugins to investigate and manipulate a request before it is send to the server (#486). 
     31    * The default topicmap view model is renderer agnostic. It is reusable by different topicmap renderer implementations (#443). 
     32* Access Control API: there are methods for retrieving topics/associations based on creator or owner (#458). 
     33* Core Service: there are methods for retrieving ''all'' topics/associations from the DB. These are useful for migrations which transform the entire database (#495). 
     34* Core API and standard plugin APIs: the get/retrieve/delete service methods no longer require the `clientState` parameter (#496). 
     35 
    1436Bug fixes: 
    15 * Login/Logout: 
    16     * Logout works for private DM installations as well. (A private DM installation is one with `read_requires_login=true`.) The missing HTTP Logout is emulated by forcing the browser to bring up a dummy login dialog (#423). 
    17     * Login works for open DM installations as well. (An open DM installation is one with `read_requires_login=false` and `write_requires_login=false`.) (#475). 
    18     * When wrong credentials are entered DM's login dialog is not overlapped by the browser's login dialog. The user stays in DM's login dialog (#471). 
    19     * When the user enters neither a username nor a password in the login dialog no exception occurs (#473). 
     37* !Login/Logout: 
     38    * Logout works for private DM installations as well. (A private installation is one with `read_requires_login=true`.) Missing HTTP Logout is worked around by bringing up a bogus browser login dialog (#423). 
     39    * Login works for open DM installations as well. (An open installation is one with `write_requires_login=false`.) (#475). 
     40    * When the user enters wrong credentials in DM's login dialog the browser's login dialog does not appear. The user stays in DM's login dialog (#471). 
     41    * When the user enters neither a username nor a password in the login dialog and presses OK no error occurs (#473). 
    2042* The type loader doesn't throw a bogus "Endless recursion" exception when repeatedly tried to load a type with an invalid URI (#487). 
    2143* Exceptions thrown from request filters (formerly servlet filters) appear in the log file (if file logging is activated) (#474). 
     
    2345    * When processing the directives of an update request the `dm4c.selected_object` is updated properly (#488). 
    2446    * Construction of the object model passed to a topic/association update request no longer manipulates the `dm4c.selected_object` in place. This allows a plugin to investigate the selected object's metadata (e.g. timestamps, access control information) before the request is send (#486). 
    25 * Requests issued by the Webclient have no superfluous "?" character at the end as it might confuse the browser's or network proxy's caching heuristic (#483). 
     47* Requests issued by the Webclient have no superfluous "?" character at the end as it might confuse the browser's or network proxy's cache heuristic (#483). 
    2648* Web application plugins (derived from `WebActivatorPlugin`) are detected as DeepaMehta plugins. The `ALL_PLUGINS_ACTIVE` event is fired properly (#498). 
    2749 
    28 Plugin Development Framework: 
    29 * A plugin can store **Node Properties**. Node properties are topic/association metadata like timestamps, ACL information, or geo coordinates. The new Property API can retrieve topics/associations based on property value or value range (#472). Node properties can be indexed. Numeric properties are trie-indexed which allows for performant range queries. Ranges are particularly useful for time-based or geo-based retrieval (#490). Property keys are namespaced (#491). 
    30 * 3 new Core Events: 
    31     * `SERVICE_REQUEST_FILTER` allows plugins to manipulate or interrupt REST service requests (#480). 
    32     * `RESOURCE_REQUEST_FILTER` allows plugins to manipulate or interrupt static resource requests (#480). 
    33     * `SERVICE_RESPONSE_FILTER` allows plugins to set certain response headers (#477). 
    34 * The Core Service provides methods for retrieving ''all'' topics/associations from the DB. These are useful for migrations which transform the entire database (#495). 
    35 * Simplified API: the Core API's and standard plugin service's get/retrieve/delete methods no longer require the `clientState` parameter (#496). 
    36 * Revised exception handling: 
    37     * A plugin can produce specific HTTP (error) responses by throwing a WebApplicationException from its resource methods or event handlers (#484, #481). 
    38     * Exceptions thrown from resource methods or event handlers must no longer be wrapped in a WebApplicationException if a 500 response is intended (#484). 
    39 * (REST) resource methods can use an arbitrary class for the entity parameter as long as the entity is represented in JSON and the class has a public JSON constructor. Implementing a custom JAX-RS provider class is no longer required (#277). 
    40 * Access Control API: there are methods for retrieving topics/associations based on creator or owner (#458). 
    41 * Webclient: 
    42     * New Webclient event (client-side): `pre_send_request` allows plugins to investigate and manipulate a request before it is send to the server (#486). 
    43     * The default topicmap view model is renderer agnostic. It is reusable by different renderer implementations (#443). 
    44 * Plugins can send REST service requests asynchronously (#476). 
    45  
    4650Further changes: 
    47 * The dependency on Felix's proprietary "Extended HTTP Service" is dropped. Thus we are ready to replace Felix HTTP Service with OPS4J Pax Web soon. OPS4J Pax Web is the far more modern and flexible OSGi HTTP Service implementation which enables a variety of new applications (#448). 
     51* The dependency on Felix's proprietary "Extended HTTP Service" is dropped. Thus we are ready to replace Felix HTTP Service with OPS4J Pax Web soon. OPS4J Pax Web is the far more modern and flexible OSGi HTTP Service implementation which enables e.g. server push and !WebSockets (#448). 
    4852* Core Service REST API: the URLs for topic/association update (PUT) requests are REST-conform (#482). 
    49 * The REST service no longer delivers user-related permission information along with topic/association responses. The permissions are explicitly retrieved through the Access Control service (#489). This makes topic/association responses cachable by the browser (#478). 
    50 * The DM Karaf distro uses same default configuration as the DM Standard Distro (#447). 
     53* The REST service no longer enriches topic/association responses with user-related permission information. Instead permissions are explicitly requested through the Access Control service (#489). This makes topic/association responses eligible for the browser cache (#478). 
     54* The !DeepaMehta Karaf Distribution uses same default configuration as the DeepaMehta Standard Distribution (#447). 
    5155* COPYRIGHT.txt is updated (#434). 
    5256 
     57See the [[https://github.com/jri/deepamehta#readme|README]] for installation and update instructions. 
    5358 
    5459----