Re: gnome-vfs/GIOChannel for parsing
- From: Colin Walters <walters debian org>
- To: gtk-devel-list gnome org, gnome-devel-list gnome org
- Subject: Re: gnome-vfs/GIOChannel for parsing
- Date: 05 Mar 2003 21:35:25 -0500
On Thu, 2003-02-27 at 18:57, Jody Goldberg wrote:
> > Storage interface? Could you explain?
> GsfInfile & GsfOutfile or in MS/Bonobo speak Storages.
> The relationship between streams and storages is fairly incestuous.
> It seems useful to work out the interface details together.
Ok, I see GsfInfile and GsfOutfile, but I don't really understand their
purpose. I couldn't find any references to Storage (besides
IsolatedStorage) in the .NET framework. I looked at the BonoboStorage
documentation, but it wasn't very enlightening either.
What do you use Storages for? How is it different from just using a
particular stream implementation?
> Stream::read is the core of any api. The exact semantics of this
> are quite important. We're defining interfaces here not
> implementations. As an example in GsfInput I made what seemed like
> a simple assumption and added a GsfInput::size method which assumed
> that we could always know the size of the data to be read when it
> was opened. This is not true for bzip2 files. Its this sort of
> thing that needs to be hashed out now.
Fair enough. In that case though you could just make the size method
return -1 or something if the size isn't known.
> We are clearly talking to cross purposes here.
Hm, I think we're mostly on the same track.
> If we define a glib
> based stream interface I would not want GsfInput/GsfOutput.
I agree!
> So yes,
> I am talking about merging parts of gsf into glib. I envision
> something on the order of gdk pixbuf. With a registry of known
> formats and interface specifications in glib. Anything less seems
> pointless.
I'm not so sure about the registry, but OK.
> While it seems useful to have an interface for async i/o I still
> fail to see how it would be the primary interface an application
> used.
It depends on the application, of course. People doing networking stuff
will want it; see the GNet library.
> I suppose I'm looking at things from a file format
> perspective rather than a transport layer, but either way it seems
> like a set of convenience wrappers for handling this is the way to
> go.
What do you mean by "convenience wrapper"? In the Mono .NET
implementation they just cheated and had the default implementations in
Stream call the blocking versions. We could similarly have the API
there, but not implement it fully until later.
> Please grab me on irc at some point to speed this conversation. We
> can post details afterward. I have the feeling that we're not
> talking about the same things.
Ok, school has been keeping me very busy, but hopefully this weekend
I'll have some time.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]