On Wed, Apr 4, 2012 at 11:49 PM, Larry Gritz <[email protected]> wrote:
> CCing oiio-dev.

Thanks!  I intended to send my previous mail to everyone, sorry.

> I can think of two reasons why you'd still want to separate them: (1)
> so you can ask for supports("blah") on the II that hasn't yet been
> opened, without the expense of the open

Wasn't the main point of the patch that create() opens and closes the
file internally, so you always have one call to open behind the scenes?
I feel like I'm missing something here.

> or on a generic II of the
> right type (think: create("tiff"));

Fair point, I can see this being somewhat useful.


Here's a different alternative - how about a new version of open() which
does a create and an open() at the same time:

static ImageInput *ImageInput::open (const std::string &filename,
                                     const std::string &plugin_searchpath="");

Then you just leave ImageInput::create() as it has always been, and
everyone can transition to this new signature as they please.

> and (2) so you can call the
> open-with-config variety: open(name,newspec,config).  The latter could
> be accomplished by having yet another call signature of create() that
> takes the config, but that would make it harder to have client
> software with special cases for individual formats (i.e., special
> config for just one type).

How so?  Don't they just call close() and then reopen again with the new
config?


> I'm also hesitant to break back compatibility, but I don't know if I
> should be.

I don't much like it either, I think the proposal above for an
alternative open() is better.

~Chris
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to