Taken to its logical conclusion, this
would become a full-fledged query language.
You could just create a client-side library for it and use that as
the "language" develops. I think that would be a safe thing to do
before committing it as part of the supported server side
interface.
How much of a problem would this be if it were not for GWT's
callback-hell? It's my understanding that GWT is fixing that?
On 10/31/2014 11:35 AM, Harald Pehl wrote:
TL;DR
For management clients it is tedious and awkward to
read resources / attributes in big domains (e.g. return the
state of all running servers across all hosts which are part of
server group "foo"). Today this requires to setup multiple
composite operations *on the client* which need to be executed
in a specific order. This proposal suggests a new operation
which collects all relevant information *on the
server* and returns only the relevant data in one go to the
client.
--------------------
# Background:
In the admin console we often need to read specific
attributes across a domain or across a deeply nested resource:
- List all enabled data sources of the current
profile
- Show the port offset of all running servers across
all hosts
- Get all users which belong to role Operator
Even for small domains with two server groups and a
small number of servers this procedure is awkward and error
prone. What makes it even more difficult is the asynchronous
nature of the admin console. Soon you end up in a deeply nested
callback-hell. Besides that these 'queries' lead to poor
performance for big domains with tens of groups, hosts and
servers.
# Proposal / Prototype
The GitHub repository at [1] contains a more
detailed description of the problem statement and a working
prototype. This includes details such as how to address the
requested resources, how the information is retrieved and how to
handle errors.
The proposal also includes a way to filter and
reduce the resources against a list of attributes and values
*before* the response is sent to the client.
---
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev