Fixing problems that aesalon has does nothing but raise more questions . . .

Fixing problems that aesalon has does nothing but raise more questions . . .

I'm beginning to wonder if I need to redesign the GUI's storage system again.
Basically, I am attempting to finish the implementation of the active blocks
graph, but it is doing nothing more than raising more questions. First off,
where are the GraphDataEngines stored? How can pointers to them be obtained?

More pressing: Why is this data-storage setup so complicated? Is it not a tad
over-done? I mean, three threads, plus one per active data display? Again, it
seems to me that I've over-designed the whole system.

So, let's see. What are the requirements for the data storage system? I like
the multiple-head binary tree, as it does a very effective job of storing
large amounts of redundant data. So, I need to be able to . . .

+ Efficiently access the current snapshot tree
+ Obtain a historical Snapshot pointer
+ Retain the ability to split storage etc. across multiple threads

In essence, I need to re-do the data viewing design. This raises two
questions: How can huge amounts of data be easily transferred between multiple
threads? Should data views have to poll for new data, or should they be
continually and automatically updated?

The best solution, I think, to the first question is to use a semaphore-
protected queue of requests, which are then processed whenever the data
storage thread is not occupied processing input from a data source . . .

The second question is a little bit more involved, and requires a little more
thought than the first. There are two separate methods of solving this
problem, as I have stated before: the state of the memory can be always kept
up-to-date, and every once in a while, send an update of the most recent
version on to the rendering/processing thread. Or, instead, the processing
thread can specifically request new data whenever it is interested in
displaying new data. The latter design works best when dealing with large
amounts of data, especially in the sort of situation that aesalon will be
dealing with much of the time, between two specific timestamps. The former is
potentially better for such things as real-time updating graphs. The issue
here is that Aesalon will have both such displays, indeed, graphs etc. will
have to implement both approaches in order to properly display all gathered
information . . .

The two solutions can be combined with a system much like what I currently
have, only re-implemented to provide a more concise and stable interface. For
the next few sentences, assume that the "processor" is the graph/display
widget, and that the "storage" is the data storage thread. The processor sends
requests to the storage, which responds in a timely manner with the data that
was requested. The processor can additionally send a request that adds itself
to a list of processors that are interested in real-time updates. In such a
case, whenever a new event is created by the storage, an update is sent to the
interested processors.

Complex . . . and not at all different than the current system. The primary
difference, I suppose, is that there is no provision for DataEngines or indeed
any type of cached data. Not a good thing, I think . . . but perhaps it is.

Very well. I shall attempt to redo the current design with a slightly better
system, e.g. no DataEngines . . .