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.
