[Kst] [Bug 123699] fails to create INDEX from .fits file binary extention

[Nicolas Brisset]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=123699         




------- Additional Comments From nicolas.brisset eurocopter com  2006-06-19 15:33 -------
Barth's opinion:

The reason to have a single length per field is to handle asyronously arriving real time data in count from end mode (ie, the #1 requirement for kst), to make sure that the X vectors and the Y vectors stay synced.  Because of this, in fact, currently, fields within a data source are required to have the same frame count.  NF is a property of a datasource.

If we can simultaneously solve syncing asyncronous fields and handling variable length fields, then that is great.  But the former has to take priority over the latter.

The fundamental problem is this:
Imagine that we are in read-from-end mode (reading 20 frames), and go to read from a potentially asynchronous data source (eg, a dirfile), and find that field X has 1001 frames, and field Y has 1005 frames.  Kst could conclude
that:
  -X is just behind, and so read 20 frames ending with 1001.
  -There are different length frames, and so read 20 frames from X ending at 1001, and 20 frames from Y, ending with 1005.

The existence of this discussion indicates that there will be times when you want one, and other times when you want the other.

Perhaps the best solution is to let the data source decide - it can know which is appropriate.

So: 
-kst learns to read NF on a per field basis, not a per data source basis.

-Data sources that need to are responsible to make sure that NF is the same for all fields.  Data sources that don't need to don't (eg: dirfiles can have a bool in the format file which tells getdata what to do here)  We keep 
datasource->update() in order for syncronized data sources to determine 
datasource->their
one and only NF.  non-sycronized data sources don't have to do anything here.  

-INDEX always returns what you ask for, without wondering if the data exists for any other fields.


Seem sensible?

The other issue we have to address is marshaled reads, like for NAD or for 
ascii.  This doesn't solve that, but may be related.