Re: gsf api thoughts

[Jody Goldberg <jody gnome org>]

On Fri, Aug 02, 2002 at 12:26:47AM -0400, Dom Lachowicz wrote:
> GsfInput::Dup

> 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?
This is indeed debatable.  There were 2 issues that it addressed
    - Reading from some ole streams required going back to the
      container for more information some times.  We could probably
      work around this.
    - Having more than 1 substream open at a time.  In outfiles this
      is not allowed.  So I suppose would could have a similar
      requirement on infiles.  Is it worth the effort ?

> GsfOutput::Close
 
> 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.

Not quite.  The stream can hold information even if it is closed.
It may still be usefil to have the stream name or size available
even when the content is committed.  Also, as Zbigniew pointed out
we may not want to rely on unref happening in a timely fashion.

> 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);
That would be a default implementation, but the stdio stream could
use fprintf directly, and any of the wrapper formats (ole, zip)
could chain directly to the underlying stream.