<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Taken to its logical conclusion, this
would become a full-fledged query language. <br>
<br>
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.<br>
<br>
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?<br>
<br>
On 10/31/2014 11:35 AM, Harald Pehl wrote:<br>
</div>
<blockquote
cite="mid:86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
TL;DR
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">--------------------</div>
<div class=""><br class="">
</div>
<div class=""># Background:</div>
<div class=""><br class="">
</div>
<div class="">In the admin console we often need to read specific
attributes across a domain or across a deeply nested resource: </div>
<div class=""><br class="">
</div>
<div class="">- List all enabled data sources of the current
profile </div>
<div class="">- Show the port offset of all running servers across
all hosts</div>
<div class="">- Get all users which belong to role Operator</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class=""># Proposal / Prototype</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">[1] <a moz-do-not-send="true"
href="https://github.com/hpehl/map-reduce" class="">https://github.com/hpehl/map-reduce</a> </div>
<div class=""><br class="">
</div>
<div class="">---</div>
<div class="">
<div apple-content-edited="true" class="">Harald Pehl<br
class="">
JBoss by Red Hat<br class="">
<a moz-do-not-send="true" href="http://hpehl.info" class="">http://hpehl.info</a><br
class="">
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
</body>
</html>