Re: paradox support: help needed

On Wed, Oct 29, 2003 at 11:54:42AM -0500, Jody Goldberg wrote:
On Wed, Oct 29, 2003 at 09:47:40AM +0100, Uwe Steinmann wrote:
yup. open and probe are the only entry points.
Implemented both. When is probe being called? Whenever a file
is opened or only if one selects auto detection in the file
open dialog?

It is used when auto detecting file type.  We first try to match by
file name (to avoid loading the probe routine).  If that succeeds we
then do a content check via probe to see if things match.

Ok. I added support for gsf to my library. Actually it's now prepared to
use any kind of io access.

great.  All kinds via libgsf ? or via a wrapper to gsf.
I can tell the library which read, write, seek and tell functions to
use. There is also a convience function which uses gsf_input_read(),
gsf_input_seek(), ... by default.

1. My library can use external memory management functions instead of
   usual system functions. Does gnumeric provide memory management which
     I should use.
Mostly no.  There are some chunk allocators that we use for speed in
places, but for the most part the stock glib g_* versions are what
we advocate.
Ok, I will use those instead malloc, realloc, free.

2. The library can also call an external error handler. Same question as
   in 1. 
What sorts of errors ?  The io_context passed into the reader is the
best place to register warnings and errors.
All kinds of errors within the library, like not sufficient memory
or passing bogus parameters to functions.
In many cases it is probably ok to through the internal error message
away and just do some more general error reporting. Though, i find
it always useful to get an error msg from the place where the error actually
occured. I guess I will have to extend my error handler with some
pointer to user data, in order to pass the io_context.

3. Paradox files usually have some codepage xxx encoding. The library
   can do the conversions on the fly when accessing character fields.
     Should this be preffered opposed to gnumerics own recoding functions?

I'll leave it to your discretion.  We obviously have more experience
with the glib variants, but you will have more domain experience on
the format requirements.
Ok, I let the library to the recoding to UTF-8. Or maybe i check first,
whether the library has recode support (which is hasn't if iconv or
recode is not available) and fall back to glib if required.

4. I currently use value_new_string_nocopy(str), with str being a
   string allocated within the library. Should I rather use
     value_new_string(str) and free the memory allocated in the library

As long as the strings are being allocated with g_malloc/g_new type
routines so that they can be freed with g_free then _nocopy is
prefereable as it saves a needless alloc/copy/free cycle.
Ok, I'll tell the library to use g_xxx functions.

5. A paradox database is usually splitted into several files, e.g. a
   primary index is put into an extra file. In general it is not
     required to read those files, but it can accelerate access.
     Is there any way to access those files in a clean way from within
     the plugin?

When can we see the code ?  It would be nice to get it in as soon as
1.3.x branches.
Do you just want to have a brief look into the plugin code or shall a
send a patch to the current cvs? The patch will contain everything,
changes to, po/, plugin/, ...

In order to test it, you will have to get pxlib from sourceforge.
I have debian packages and could create untested rpms.


  MMK GmbH, Universitaetsstr. 11, 58097 Hagen
  Uwe Steinmann mmk-hagen de
  Tel: +2331 840446    Fax: +2331 843920

Attachment: signature.asc
Description: Digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]