[Kst] New virtual method(s) in kstdatasource ?

[George Staikos]

On Tuesday 19 October 2004 08:39, Nicolas.Brisset at eurocopter.com wrote:
> I wanted to implement support for a in-house format which I unfortunately
> cannot change and don't have the specs for. So I am stuck with the current
> library and have to use its functions. Now, there is the following problem:
> to get data I have to open the file with a function whose arguments contain
> the list of fields I'll be reading. As the open/close operations are
> awfully slow, it is not realistic to call the corresponding functions in
> each readField() call.
> Would it be possible to add a new virtual method in kstdatasource that
> would be something like readList(const QStringList& fieldsToRead) and
> inform the datasource of the fields that are _going to be read_ before the
> calls to readField() happen ?
> The base implementation could do nothing as existing datasources do not
> need this, but I can imagine it could be useful in other cases as well.
> Maybe we'd actually need two methods: one to add, the other to remove
> fields from the list of fields read from that source. It depends on the
> objects that manage these calls and I don't know how they work...

  Yes it's quite easy to add this, but I'm not sure exactly how we would call 
this yet.  This is a major issue to resolve before 1.0 because it requires 
binary incompatible changes.  Now, here is what I think of this:

- We can easily call this method when we create RVectors, and call the remove 
method when we delete an RVector, but is that efficient enough for you?
- In the data manager, we can further optimize by calling it before creating 
the RVectors but it will require a slightly more messy RVector interface for 
us.
- It will require a sort of reference counting per field since the same field 
can be read multiple times.

Given that, do you gain any tangible benefit from closing fields on the fly?  
If not, you could maintain this list yourself and just update it when you see 
a read on a field you didn't see in the past.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/