RE: [Pspp-cvs] Changes to pspp/src/algorithm.c

[Marshall DeBerry]

Just one thought in this thread regarding a future gui interface.  Keep in
mind that others will want to port pspp to other architectures, in my case,
OS X with the Quartz gui architecture.  Hopefully any decisions you make
won't be too tied to a library set that will make it very difficult when
porting to another gui environment.
  Marshall


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of John Darrington
Sent: Tuesday, October 25, 2005 12:38 AM
To: Ben Pfaff
Cc: address@hidden; John Darrington
Subject: Re: [Pspp-cvs] Changes to pspp/src/algorithm.c

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.