Changes between Version 70 and Version 71 of ReleaseNotes
- Timestamp:
- 29.08.2013 16:36:09 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ReleaseNotes
v70 v71 7 7 == ''upcoming:'' DeepaMehta 4.1.1 == 8 8 9 While !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 11 You can update an existing !DeepaMehta 4.1 installation while keeping all your data or perform a !DeepaMehta 4.1.1 clean installation. 9 While !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 Edit Conflict Detection for supporting collaborative work. Furthermore, plugin developers can attach arbitrary metadata to topics and associations. Numeric metadata is [[http://en.wikipedia.org/wiki/Trie|trie-indexed]] which make it suitable for time- and and geo-based range queries. 10 11 You can update an existing !DeepaMehta 4.1 installation while keeping your content or you can perform a !DeepaMehta 4.1.1 clean installation. See the [[https://github.com/jri/deepamehta#readme|README]] for installation and update instructions. 12 13 CHANGELOG 12 14 13 15 New features: 14 * **Timestamps** (#386). Each topic/association have creation and modification timestamps. T opics/associations retrieved via REST are attributed with these timestamps. The new Time API allows programmatic timestamp access and topic/association retrieval based on time ranges. Timestamps are also the basis for validating the browser cache and for edit conflict detection. The time aspect is realized as a separate module (`dm4-time`).16 * **Timestamps** (#386). Each topic/association have creation and modification timestamps. Timestamps are delivered along with topics/associations retrieved via the REST API. The new **Time API** allows programmatic timestamp access and topic/association retrieval based on time ranges. Timestamps are also the basis for validating the browser cache and for Edit Conflict Detection. The entire time aspect is realized as a separate module (`dm4-time`). 15 17 * **Exploiting the browser cache** (#478). Consequent usage of intrinsic HTTP features (`Last-Modified` and `Cache-Control` response headers and `If-Modified-Since` request header) results in lesser network traffic and better perceived performance. The caching aspect is realized as a separate module (`dm4-caching`). 16 * **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.18 * **Edit Conflict Detection** (#479). The server rejects a PUT request when the resource has changed meanwhile. The check is based on the resource's modification timestamp. This fights the "lost update" problem when working collaboratively. Edit conflict detection is realized at HTTP level, that is a conditional PUT request (involving an `If-Unmodified-Since` request header). Conflict ''resolution'' is not yet realized. 17 19 18 20 Plugin 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).21 * The new **Property API** allows plugins to attach Node Properties to topics and associations. Node properties are metadata like timestamps, ACL information, or geo coordinates. Topics/associations can be retrieved based on property value or value range (#472). Node properties can be indexed. Numeric properties are trie-indexed which allows for performant range queries (#490). Property keys are namespaced (#491). 20 22 * HTTP response generation: 21 * A plugin can produce specific HTTP (error) responses by throwing a WebApplicationExceptionfrom its resource methods or event handlers (#484, #481).22 * Exceptions thrown from resource methods or event handlers must no longer be wrapped in a WebApplicationExceptionif a 500 response is intended (#484).23 * (REST) resource methods can use an arbitrary class for the entity parameteras 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).23 * A plugin can produce specific HTTP (error) responses by throwing a `WebApplicationException` from its resource methods or event handlers (#484, #481). 24 * Exceptions thrown from resource methods or event handlers must no longer be wrapped in a `WebApplicationException` if a 500 response is intended (#484). 25 * The entity parameter (represented in the message body) of a REST resource method can use an arbitrary class 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 26 * 3 new Core Events: 25 27 * `SERVICE_REQUEST_FILTER` allows plugins to manipulate or interrupt REST service requests (#480). … … 29 31 * (Client-side) plugins can send REST service requests asynchronously (#476). 30 32 * 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 differenttopicmap renderer implementations (#443).33 * The default topicmap view model is renderer agnostic. It is reusable by custom topicmap renderer implementations (#443). 32 34 * Access Control API: there are methods for retrieving topics/associations based on creator or owner (#458). 33 35 * 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).36 * Core API and standard plugin APIs: the `clientState` parameter is no longer required in get/retrieve/delete service methods (#496). 35 37 36 38 Bug fixes: … … 43 45 * Exceptions thrown from request filters (formerly servlet filters) appear in the log file (if file logging is activated) (#474). 44 46 * Webclient model update: 45 * When processing the directives of an update request the `dm4c.selected_object` is updated properly(#488).47 * When processing the directives of an update request the `dm4c.selected_object` is properly updated (#488). 46 48 * 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). 47 49 * 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). 48 * Web application plugins (derived from `WebActivatorPlugin`) are detected as DeepaMehta plugins. The `ALL_PLUGINS_ACTIVE` event is fired properly (#498).50 * Web application plugins (derived from `WebActivatorPlugin`) are detected as !DeepaMehta plugins. The `ALL_PLUGINS_ACTIVE` event is fired properly (#498). 49 51 50 52 Further changes: 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).53 * 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 (#448). OPS4J Pax Web is the far more modern and flexible OSGi HTTP Service implementation which enables e.g. server push and !WebSockets as well as binding the web server socket to a specific network interface (#39). 52 54 * Core Service REST API: the URLs for topic/association update (PUT) requests are REST-conform (#482). 53 55 * 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 theDeepaMehta Standard Distribution (#447).56 * The !DeepaMehta Karaf Distribution comes with the same default configuration as the !DeepaMehta Standard Distribution (#447). 55 57 * COPYRIGHT.txt is updated (#434). 56 57 See the [[https://github.com/jri/deepamehta#readme|README]] for installation and update instructions.58 58 59 59 ----