[Kst] Re: CDF datasource (again)

[Nicolas.Brisset at eurocopter.com]

On Tuesday 03 August 2004 19:15, George Staikos wrote:
>    Ok we can work around this.  Changing the state of Kst from the
> datasource is a bit unorthodox and I really hesitate to add this right now.
I understand it may lead to some strange behavior from the user's perspective, 
unless we warn the user by some means. I just mentioned this as it seemed 
pretty easy to do :-)

>  However we could guard the datasource functions a mutex.  It will make
> things a bit choppy during loading, but I'm sure that's acceptable.
That sounds a bit frightening (I have never programmed anything with threads), 
but why not (time to learn ?)... I could give it a try (QMutex ?) but before 
I do that, I have a question: 
One thing I was wondering is whether some functions could cache their result 
in private variables (like the field list or frame counts). As I don't expect 
many streaming cdf uses, frame counts for example will never change. Instead 
of reopening the file each time a frame count is queried (and needing to 
protect this operation with a mutex) we could cache it I guess. I just don't 
know for which functions it makes most sense... I'd suggest caching field 
list and frame counts, which would mean isValidField(), frameCount() and 
possibly even fieldList() (if the data is initialized in the constructor for 
instance) would not need to open the CDF file at all, which is by the way a 
rather slow operation. If we do this, only readField (and maybe the 
constructor ?) would need physically access the file and need to be 
protected. Sounds good to me but I am not completely sure it is a good idea ?

Nicolas