Re: import/export interface for Bonobo



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]