<br>Any thoughts about suppression of Dimension default members from the slicer axis? That's the other area of substantial overhead for us.<br><br>I like the idea of the XMLA request specifying the content it wants with a property like <span><font color="#000080" face="Lucida Sans" size="2">Content=DataWithoutInfo</font></span>. We would need to find some way to modify the Cognos XMLA request before passing it on, but that shouldn't be difficult.<br>
<br><br><div class="gmail_quote">On Fri, Aug 7, 2009 at 2:23 PM, Julian Hyde <span dir="ltr"><<a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="im">
<div><font color="#000080" face="Lucida Sans" size="2"></font> </div><font color="#000080" face="Lucida Sans" size="2"></font><font color="#000080" face="Lucida Sans" size="2"></font><br>
<blockquote style="border-left: 2px solid rgb(0, 0, 128); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div dir="ltr" align="left" lang="en-us"><span><font color="#000080" face="Lucida Sans" size="2"> Matt Campbell wrote:</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span></span><span><font color="#000080" face="Lucida Sans" size="2"> </font></span></div>
<div dir="ltr" align="left" lang="en-us">I think
compression is a great idea, but it won't really help in our case, since we
have no control over the XMLA client (Cognos). It'll actually be the
rare case where you could influence the HTTP request of a 3rd party
client.<br><br>And even if we <i>could</i> compress the response for Cognos,
we would still have a performance issue. From what we've seen the bulk
of the time is spent processing the large response. Network overhead is
a fraction of that (we're running over a gigabit network--network time for
these responses is milliseconds).</div></blockquote>
</div><div><span><font color="#000080" face="Lucida Sans" size="2">My comments about CPU benefit were aluding to that. A verbose
protocol can have impact in CPU & bus utilization as well as network
throughput & response time. The response would become large at some part of
the pipeline, but there would still be savings in the network
stack.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">But anyway. It's clear that this won't work for
you.</font></span></div><div class="im">
<blockquote style="border-left: 2px solid rgb(0, 0, 128); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>Given that, I'd still like to see a way to trim down the response. From a
scan of the spec I don't see anything that says that some content is
mandatory.<span><font color="#000080" face="Lucida Sans" size="2"> </font></span></div></blockquote>
</div><div><span><font color="#000080" face="Lucida Sans" size="2">My reading of the spec is that if a provider does not return,
say, OlapInfo, then it is not in compliance with the spec. There's no way in the
spec for a client to say it DOES NOT want OlapInfo, and therefore the server has
to provide it. So, the content is mandatory.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">The spec allows some control over what comes back, using the
Content=(None|Schema|Data|SchemaData) attribute. Page 51 of <a href="http://www.xmla.org/xmla1.1.doc" target="_blank">http://www.xmla.org/xmla1.1.doc</a>. We
implement that of the spec.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">I propose that we allow alternative values for that
attribute, say Content=DataWithoutInfo. (Or suggest a better term.) This would
be an extension to the spec, and probably you would be the only client using it,
but I would allow it because it wouldn't require a lot of code changes to
the server.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">I looked over the olap4j driver (XmlaOlap4jCellSet.java) and
it looks like it does need the OlapInfo element. So, the olap4j driver would
need to use a compression approach, not your approach of omitting elements. Luc,
let's discuss this in another thread.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">By the way, I came across Microsoft's patent. Obviously we do
NOT want to implement this in Mondrian! <a href="http://www.freepatentsonline.com/y2006/0026167.html" target="_blank"><font face="Times New Roman" size="3">http://www.freepatentsonline.com/y2006/0026167.html</font></a></font> </span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div><font color="#888888">
<div><span><font color="#000080" face="Lucida Sans" size="2">Julian</font></span></div></font></div>
<br>_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
<br></blockquote></div><br>