[MOAB-dev] Reader/Writer filename extension access

[Jed Brown]

Apologies for jumping in late and replying to several comments at once.

On Fri, 30 Apr 2010 14:23:49 -0500, Jason Kraftcheck <kraftche at cae.wisc.edu> wrote:
> Apologies for replying to my own message.  If we do choose to go the route
> of supporting format-specific options, then I think the best way to do that
> is to have an option in the string of options that indicates that all
> following options (up to the next whatever) apply only to a specific file
> format.  Using an "every thing after this" type scheme avoids the need to
> introduce some other syntax/separator to the option string itself.
> 
> An example:
> 
> options="PARALLEL;EXODUS;PARTITION=MATERIAL_SET"

You have to be able to end the group, otherwise you're basically
hard-coding the reader.

Tim wrote:
> There should be *some* mechanism for an application to know an option
> wasn't processed, shouldn't there?

I think this is important and it's the reason I don't like the
big-ball-of-strings-passed-together API.  Furthermore, I think there
should be a clear distinction between "advice" and mandatory options.

Paul wrote: 
> This is a run-time change in available features based on the format of
> the file.

Why branch on the implementation instead of the feature?  Consider what
happens if a different format supports this feature, when you check the
implementation, you prevent this new implementation from working with
your code.  The correct thing is to branch on the capability, not the
format name.

Jed