Changes between Version 66 and Version 67 of ReleaseNotes

Timestamp:

23.08.2013 15:18:26 (12 years ago)

Author:

jri

Comment:

4.1.1 release notes, pt. 4

ReleaseNotes

@@ -8 +8 @@
 
 New features:
-* **Timestamps** (#386). Each topic/association have creation and modification timestamps. Topics/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.
-* Better performance through exploiting the browser cache (#478).
-* **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. (Conflict ''resolution'' is not yet realized.)
+* **Timestamps** (#386). Each topic/association have creation and modification timestamps. Topics/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`).
+* **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`).
+* **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.
 
 Plugin Development Framework:
 * 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).
 * 3 new Core Events:
-    * SERVICE_REQUEST_FILTER allows manipulation and interruption of REST service requests (#480).
-    * RESOURCE_REQUEST_FILTER allows manipulation and interruption of static resource requests (#480).
-    * 
+    * `SERVICE_REQUEST_FILTER` allows plugins to manipulate or interrupt REST service requests (#480).
+    * `RESOURCE_REQUEST_FILTER` allows plugins to manipulate or interrupt static resource requests (#480).
+    * `SERVICE_RESPONSE_FILTER` allows plugins to set certain response headers (#477).
 * The Core Service provides methods for retrieving ''all'' topics/associations from the DB. These are useful for migrations which transform the entire database (#495).
 * Simplified API: the Core API's and standard plugin service's get/retrieve/delete methods no longer require the `clientState` parameter (#496).
 * Revised exception handling:
-    * A plugin can produce specific HTTP (error) responses by throwing a WebApplicationException from its resource methods or event handlers (#484).
+    * A plugin can produce specific HTTP (error) responses by throwing a WebApplicationException from its resource methods or event handlers (#484, #481).
     * Exceptions thrown from resource methods or event handlers must no longer be wrapped in a WebApplicationException if a 500 response is intended (#484).
 * Access Control API: there are methods for retrieving topics/associations based on creator or owner (#458).
+* New Webclient event (client-side): `pre_send_request` allows plugins to investigate and manipulate a request before it is send to the server (#486).
+* Plugins can send REST service requests asynchronously (#476).
 
 Further changes:
 * The dependency on Felix's proprietary ExtHttpService is dropped. We are ready to replace Felix HTTP Service with OPS4J Pax Web. OPS4J Pax Web is a far more modern and flexible OSGi HTTP Service implementation which enables a variety of new applications (#448).
 * The REST service no longer delivers user-related permission information along with the topics/associations. Instead the Access Control API provides methods for retrieving the permissions explicitly (#489). This makes topic/association responses cachable by the browser (#478).
+* Core Service REST API: the URLs for topic/association update (PUT) requests are REST-conform (#482).
 
 Bug fixes:
 * Web application plugins (derived from WebActivatorPlugin) are detected as DeepaMehta plugins. The ALL_PLUGINS_ACTIVE event is properly fired (#498).
-* Exceptions thrown from request filters appear in the log file (#474).
-* When processing the directives of an update request the object dm4c.selected_object (part of the Webclient model) is updated properly (#488).
+* Exceptions thrown from request filters (formerly servlet filters) appear in the log file (#474).
+* Webclient: when processing the directives of an update request the `dm4c.selected_object` (part of the Webclient model) is updated properly (#488).
+* Webclient: 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 actually send (#486).
 * The type loader doesn't throw a bogus "Endless recursion" exception when repeatedly tried to load a type with an invalid URI (#487).
+* 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).
+* Login works with an open DM installation as well. (An open DM installation is one with read_requires_login=false and write_requires_login=false) (#475).
+
 
 == 2013-03-11: DeepaMehta 4.1 ==