[MOAB-dev] Reader/Writer filename extension access

[Paul Wilson]

Robert Smith wrote:
>
> On Apr 30, 2010, at 9:05 AM, Jed Brown wrote:
>
>> On Fri, 30 Apr 2010 09:01:09 -0500, Robert Smith 
>> <smithrm at mcs.anl.gov> wrote:
>>> What do you mean by "not part of the MOAB API"?  We can't dictate the
>>> structure of the Readers/Writers?
>>
>> I think Jason's point was that it's unacceptable for client code to have
>> a dependency on the implementations.
>
> Do you mean the code that uses the Readers/Writers?  I would agree, it 
> should not depend on the implementation.  But does that mean no client 
> code can know which particular Reader/Writer it is using?  If that's 
> true then the entire purpose of the ticket seems moot.
>
> If that's not what you mean then I don't see how my suggestions open 
> the implementation to the users.  They are just new member functions.
I'm going to try to jump in here since I think some of our usage 
patterns may have prompted the request for this.  (Ignore me if I am 
wrong...)

With the current file handling capability of MOAB based on extension 
and/or just trying a Reader until one works, user code can simply 
forward a filename to the load_file method and get back some result.  
However, the user may want to perform a variety of tasks in their code 
based upon which kind of file was sent to MOAB.  For example, in DAGMC, 
we may want to have some optional capabilities available if the user 
provides an geometry file (ACIS) rather than a mesh file (MOAB).  This 
is a run-time change in available features based on the format of the file.

It is difficult for a user to determine any kind of unique and robustly 
identifying information about which reader actually was invoked (will be 
invoked) to read the file in question from the MOAB API.  Instead the 
user tends to reimplement the same kind of code that MOAB uses (string 
comparisons on filename extensions) but with little/no code reuse (don't 
actually know which extensions are handled by which reader) and huge 
potential for inconsistency.

So, in summary, if the user code wants to branch based on which reader 
is invoked by MOAB, it is not obvious how to do this robustly.  I think 
this is the origin of this ticket???

Paul

-- 
Paul Wilson

-- ------------------------------------------------------------------ --
Paul P.H. Wilson              419 Engineering Research Building
wilsonp at engr.wisc.edu                       1500 Engineering Dr
ph/fax: 608/263-0807                          Madison, WI 53706

           My calendar: http://bit.ly/pphw-calendar

       Computational Nuclear Engineering Research Group
               http://cnerg.engr.wisc.edu

          Associate Professor, Nuclear Engineering
              Engineering Physics Department     
               http://www.engr.wisc.edu/ep       

        Chair, Energy Analysis & Policy Certificate
         Nelson Institute for Environmental Studies
                http://nelson.wisc.edu/eap/

          Contributing to the joy and improvement
                  of all those around me

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3297 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100430/56d06af4/attachment.bin>