Re: paradox support: help needed
- From: Jody Goldberg <jody gnome org>
- To: uwe steinmann cx, gnumeric-list gnome org
- Subject: Re: paradox support: help needed
- Date: Wed, 29 Oct 2003 11:54:42 -0500
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
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.
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
2. The library can also call an external error handler. Same question as
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
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
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
] [Thread Prev