[Kst] The stand-alone GetData and kst

[D. V. Wiebe]

I've released a stand-alone version of the C GetData library, available
from SourceForge:

http://getdata.sourceforge.net/

My plan (in consultation with Barth) is to replace the getdata code
(getdata.c &c.) in the kst-2.x tree with an external dependency on this
stand-alone library, like many of the kst data sources are.  I will
begin the job of incorporating these changes into the kst-2.x tree soon
(one we're certain the GetData release is reasonably useable.)

Having a stand-alone GetData library is necessary to address the
multiple forks of GetData which have developed at the various
experimental collaborations which use GetData for quick-look and data
analysis.

My questions for the kst developers are these:

Q1:  Should an external dependency to this stand-alone version of GetData
     replace the getdata library in the kst-1.x tree as well?  I see three
     possible answers to this question, none of which I'm particularly
     unhappy with:

A1a: Yes.

A1b: No, but the source code for the new GetData release should be
     copied into the kst-1.x tree.

A1c: No, but bug-fixes made in the new GetData release should be
     back-ported to the kst-1.x tree.



Q2:  How should we encourage the external GetData dependency in kst-2.x
     (and potentially 1.x) to be handled by downstream package creators?
     Is a kst without dirfile support of practical use?  I see two
     posibilities:

A2a: Let the downstream packager worry about it completely.  Encourage
     them to build kst against a GetData library which they would also
     have to package and distribute.  If they don't do this, their kst
     packages will not contain getdata support.

A2b: Have the kst-2.x configure script check for an external GetData
     library, and use it if found, but build an internal version
     distributed with the tarball if it doesn't find one.  This would
     likely result in most downstream packagers creating a kst package
     which also contains getdata.

Of thses, I prefer A2a, since A2b prevents users of the kst package
from upgrading their GetData library separately from kst, although it
does ensure all kst packages will contain GetData support.

-dvw
-- 
Don Wiebe                                   dwiebe at physics.utoronto.ca
Dept. of Physics/Univ. of Toronto
60 St. George St.                           Tele: +1-416-946-0946
Toronto ON                                  Lab:  +1-416-946-0516
Canada   M5S 1A7                            http://ketiltrout.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20080915/49279604/attachment.sig