Re: import/export interface for Bonobo
- From: Maciej Stachowiak <mjs eazel com>
- To: Dan Winship <danw helixcode com>
- Cc: Miguel de Icaza <miguel helixcode com>,Michael Meeks <mmeeks gnu org>, gnome-components-list gnome org
- Subject: Re: import/export interface for Bonobo
- Date: 17 May 2000 11:49:00 -0700
Dan Winship <danw@helixcode.com> writes:
> > So it seems to me like the right place to put typing information might
> > be the Stream interface, not PersistStream. A Stream could have an
> > optional associated MIME type which the component implementing
> > PersistStream could check when reading. Typing on an output stream
> > could be considered purely a hint, perhaps.
>
> That was going good until the last sentence. Remember that I need to
> be able to request both text/plain and text/html from the editor. Or
> by "purely a hint", do you just mean "we won't hold it against
> components written to the old interfaces if they don't support this"?
> I think we should require components (at least in the future) to
> either obey the type or raise an exception, rather than forcing the
> receiving end to check that the data is the correct type (which, as
> has been pointed out, he may not be able to do).
You are right, the last fragment of that thought was half-baked. I'm
not even sure why I suggested it.
> Or does the persister just reset the type of the stream to the type he
> wants it to be if he can't deal with it how it is? That feels wrong.
>
> > With OAF you can already determine statically what mime types a
> > component supports
>
> However, it may not be able to convert between any two types that it
> supports, and thus it may not always be able to export data in all of
> its supported types. Of course, if there's an exception that can be
> raised in this case, the receiver could just iterate through the types
> it wants to try until it finds one that works. This seems like more
> effort than just asking "what types can you export" though.
So what you're saying is that the available output types can change
dynamically. I think you are actually right; for instance, I can
imagine a component that could read, write and display both PostScript
and PDF but could not convert between them. So it's clear that dynamic
query for available output types is useful.
> There's also the compound-document nature of HTML to deal with,
> although maybe that's what Storages are for?
That might be a good way to deal with it.
- Maciej
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]