Re: paradox support: help needed

[Jody Goldberg <jody gnome org>]

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.

> After doing all the preparation work, I started to implement the plugin
> and got it already working. It's been easier than I thought.
> I doesn't support all the different field types yet, but can handle the
> most common ones. Anyway there are still some open questions.

Lovely.

> 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.

> 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.

> 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.

> 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
>        afterwards?

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.

> 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?

no.  Although that has come up once before in the context of
conglomerate and xml entities.  It should be feasible with some
extension of libgsf.  I'll add that in the TODO list.

When can we see the code ?  It would be nice to get it in as soon as
1.3.x branches.