Query Server

[Dane Gardner]

Glancing through my proof-of-concept Python code for the server side,
I remember now that I was having problems using the full spectrum of
commands with the Python interface, so it was easier to use the
'cmd_parse' method (which is not part of the official interface) to
directly query the CLI with text queries. This was simple and
effective --and is probably the way that I'll go with my C/C++
version.

I also remember my biggest problem was parsing the returned data.
It's okay as a string, but the spacing was kinda hard to mess with.
Has the Open|SpeedShop group ever looked at having a CSV option on the
queries?

[JimG (jegkas-gmail)]

From what I know the current GUI. Sends down the CLI commands and then
picks the returned data up from a CLI/GUI interface found in the
attached file using routines like this and its variations:
CLIInterface::getIntValueFromCLI. However, I tried separating the GUI
from the rest of the OSS code as an experiment and found other
connections that didn't make it as modular as advertised. I think I
have some notes somewhere on this.

To more address your question, Don M, Dave W and I met a few months
ago and discussed changing the form of the data being sent to the GUI.
I believe csv was one format discussed.

This brings up the whole topic of how and where to cache the data so
that the user doesn't have to wait extremely long periods of time to
view the data.
One idea is some form of pre-computation and and saving that
precomputed data to be sent to the GUI in the database instead of the
CLI recomputing it each time. That would be a task to be done in
phaseII, if we were to win that.

Maybe Dave and/or Don remember more about that discussion and the
direction that would be beneficial to take?

Thanks
Jim G

[Dane Gardner]

I think several 'depths' of cache are necessary for static data.

Dumb caching at the client. Multiple requests to the server for the
same exact query, would be silly. This data should be stored
locally. ie, if I click on a view, wait for the calculations, click
on another and then come back to it, I should not have to wait again
for the calculations and server comms.

In that same vein, the query server should have a cache to return the
same results to multiple clients. If more than one client is
connected to the same database, it's trivial to give them all the same
data without even querying OSS. Of course, there will have to be some
way of 'expiring' the cached components.

At the OSS/CBTF level there should be some measure of storing the data
to disk. I think we've all come to realize that re-calculating some
of the larger datasets is more costly than retrieving the calculated
data from disk.