Scalable path permissions with easier configuration
Path permissions have been overhauled. Millions of path permissions are now supported.
We have redesigned the path permission system so that it is more flexible
In the old system, if you granted permissions for path a/b to role ALICE, that role
would get access to all branches under a/b. If you then granted permissions for path
a/b/c to role BOB, an ALICE session could not access a/b/c or anything below.
In the new system, path permissions do not interact between roles (permissions are composable), making
it much easier to have fine-grained path permissions for each role. The simple rule is that a session
has a permission if any of its assigned roles has that permission.
There's a new isolate path feature which enables a branch of the path hierarchy to have its own
independent path permissions, so you can reproduce any configuration you had in the old system.
When you upgrade from a previous version, Diffusion will automatically convert your existing path permission
configuration to the new system, ensuring that the behavior doesn't change.
Remote topic views provide a new way to replicate a set of topics to a remote secondary server,
which is useful to avoid geographical latency.
In previous Diffusion versions, this was achieved with fan-out.
Unlike fan-out, setting up a remote topic view doesn't require restarting the server. A remote topic view can easily
be created from the web-based management console or via the API.
You can also combine remote topic views with all the other data transformation capabilities of topic views.
You can now create delayed topic feeds using topic views. A delayed feed shows the state of a set of topics
as it was a certain time in the past (including the topic values and the branch structure).
(Don't confuse this with topic throttling, which limits the rate of changes to a topic).
With delayed topic views, you can have a branch of your topic tree that contains live data, and then create
a delayed feed which publishes the state of the data, exactly as it was an hour ago,
Diffusion 6.5 adds instant updating of subscriptions when a client session's read_topic permissions change.
Before 6.5, if the topics that a session could read changed, existing subscriptions were not affected.
Now changes to path permissions immediately affect subscriptions.
Sessions will be unsubscribed from topics for which they have lost read permission.
Topic selectors are re-evaluated, so sessions will be subscribed to topics for which they have gained read permission.
This makes it easy to implement a more dynamic security model and control access in real time.
Cluster-aware request-response messaging and control operations
Your application can now create a shared Diffusion session that can be used by multiple browser tabs.
So if your Diffusion-powered web app involves multiple pages, or users tend to open it in multiple tabs at the same time,
session management is now much easier, speeding up development and reducing server load.
Better cluster readiness management: clustered servers can now be configured to wait
until configuration or topics have been restored before connecting outside the cluster.
Smarter delta calculation: Diffusion
can now adjust the time spent calculating deltas to optimize CPU usage.
Log4J session context: from this release, the session ID and security principal
are included as additional fields in log messages when available, for easier debugging and monitoring.
Deprecations and removals
The long-deprecated ability to run server-side publishers written in Java has been now been removed.
Clients provide a more flexible and scalable way to publish topics, and any publishers should be replaced with clients.
The Publisher API is now known as the Server API and retains functions for server configuration and running
a Diffusion server embedded in a Java application.
The older one-way messaging system has been removed, and is replaced by the
more capable request-response messaging.