From: Dom Lachowicz (doml@appligent.com)
Date: Fri Aug 02 2002 - 00:26:47 EDT
Hi Jody,
I'm actually not convinced that two of your virtual methods are needed. Particularly, these are:
GsfInput::Dup
GsfOutput::Close
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));
g_free(str);
Dom
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
> implement.
This archive was generated by hypermail 2.1.4 : Fri Aug 02 2002 - 00:34:10 EDT