From: Jody Goldberg (jody@gnome.org)
Date: Fri Aug 02 2002 - 09:46:03 EDT
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.
This archive was generated by hypermail 2.1.4 : Fri Aug 02 2002 - 09:53:00 EDT