[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pspp-cvs] Changes to pspp/src/algorithm.c
From: |
John Darrington |
Subject: |
Re: [Pspp-cvs] Changes to pspp/src/algorithm.c |
Date: |
Tue, 25 Oct 2005 12:38:03 +0800 |
User-agent: |
Mutt/1.5.9i |
On Mon, Oct 24, 2005 at 08:38:06PM -0700, Ben Pfaff wrote:
If I recall correctly, you're aiming to produce import/export
filters for OpenOffice (or related software). I don't know
whether a library is the best way to do this, at least for now.
Separating out the necessary code may be difficult, and the
result may be ugly.
Gnumeric import/export filters is certainly one purpose. But also makes
a gui easier to develop. If we don't have a seperate libary, then the
alternatives are: a) have the gui inextricably entwined in the pspp code;
or b) Duplicate large parts of pspp internals in the gui.
Furthermore, if the library is to be used by
external code (not just by code in the PSPP codebase), then it
commits us to a particular ABI, so that if we change internals
that the library includes (and we certainly will), then it breaks
the external code. The latter is what really worries me. I
really don't want to commit to any ABI now.
I agree that perhaps it's premature to make that commitment now. But I don't
think it's a bad thing to do ultimately. And if we can do that separation
now it'll be easier to think (at least for me) how an ABI ought to look.
So my suggestion is that we should really do one of the
following:
1. Separate the library but only use it within the PSPP
source tree. Use it to write program(s) to convert
PSPP file formats to/from other formats.
or
2. Add PSPP command line syntax that causes PSPP to just
do a file conversion and exit, when invoked as
e.g. `pspp --convert --from foo.dat --too foo.xml'.
That way we don't even have the separate the library.
I think I prefer #2.
What do you think?
For a gui I think #2 would be unworkable. It would have to open a pipe and
do a conversion on every button click, expose event etc. Even if we had
a multithreaded application and could cope with the latency, there'd be a lot
of code to parse some internal gui format which wouldn't be used for anything
else and would be quite ugly.
I'd much prefer #1, and let the gui make a simple wrapper around the pspp
objects (eg dictionary) which can emit their own signals. Let's just define
the "PSPP source tree" to include the gui.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature