Re: gsf api thoughts

Hi Jody,

I'm actually not convinced that two of your virtual methods are needed. Particularly, these are:


I really don't see the why dup was needed. In some cases, it ref's an internal stream and returns. In other cases, it opens a new copy of its resource and returns. Fine, but what uses this?

My major concern was with Close, though. I think that to close a stream, one would simply unref the object. When the ref count goes to 0, the object closes any internal streams or frees the relevant data. I see no need for both Close and unref to exist, mainly because there's nothing one can do with a closed stream besides unref it.

As for gsf_output_printf, are you suggesting something that would be functionally equivalent to the following code, or am I misunderstanding you?

char * str = g_strdup_printf ( format, args ) ;
gsf_output_write(str, strlen(str));


On Thursday, August 1, 2002, at 10:47  PM, Jody Goldberg wrote:

libgsf development is coming along.  Tambet has finished a first
pass at zip file import and has started on zip export.  It is now
trivial to add a wrapper which would support the OO style zip files.

Dom and I discussed a doc meta data api, and appear to have collided
on an implementation.  However, while playing with converting the
rest of gnumeric's export plugins to use libgsf I've come across 2
api issues that could use some imput.

1) gsf_output_printf (and friends)
On the input side I got a gsf_input_textline class to handle reading
text sources line by line (1 byte encoding or utf8).  That seems
reasonable.  Line by line text seems like a format.  On the output
side it is less clear.  It would be useful to have the printf
routine in the base class, but this introduces an asymetry in the
interface.  Any preferences ?

2) output unref vs close.  Should unrefing an output close it ?
I suspect so given that any other behaviour would be much harder to

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