Re: gsf api thoughts

From: Dom Lachowicz (
Date: Fri Aug 02 2002 - 00:26:47 EDT

  • Next message: Dom Lachowicz: "Commit: fix bug 3840"

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

    This archive was generated by hypermail 2.1.4 : Fri Aug 02 2002 - 00:34:10 EDT