On Apr 4, 2012, at 7:30 AM, Chris Foster wrote:
> 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.
valid_file would let the create-without-open variety to just return the right
kind of ImageInput for that file type, but not open the file even once. Maybe
you want a fully generic one. Or maybe you want to create the II but stash it
for opening later on.
> 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.
I kind of like that! Let me mock it up and see how it feels.
>> 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?
Sure. But if you have an efficient valid_file(), create-without-open +
open-with-config is more efficient than create-with-open + close +
open-with-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.
I'm leaning this way, too. Will follow up later today if I get the chance.
-- lg
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
