[ITK-dev] Proposal: file reader API additions to eliminate need for guessing pair file paths

[Johnson, Hans J]

Sean,

I think that an API to provided overloading to SetFilename() would be nice.

SetFilename(std::string myfilename)  …. Of course keep the old name.
{
   NewIOStreamObjectExtractorThingy *  nios  = NewIOStreamMultiFileObject();
   nios.SetHeaderInformation( myfilename );
   SetFilename( NewIOStreamObjectExtractorThingyBaseClass * nios);
}


NewIOStreamObjectExtractorThingy *  nios  = NewIOStreamMultiFileObject();


nios.SetHeaderInformation(“my.hdr”);
nios.SetDataStream(“my.img”);

SetFilename( NewIOStreamObjectExtractorThingyBaseClass * nios) … To support new IO mechanism flexibility.



===========
I’m trying to think of an interface that would support interfacing with databases or URL’s.

Hans


On 1/8/16, 1:00 PM, "Insight-developers on behalf of Sean McBride" <insight-developers-bounces at itk.org on behalf of sean at rogue-research.com> wrote:

>Hi all,
>
>Some (annoying) file formats like Analyze and PhilipsREC come in pairs: one metadata file and one data file, ex: .hdr & .img and .par & .rec.
>
>The reader classes currently take the path to one of the files and then auto-guess/construct the other path.  Of course this works most of the time, but is fragile for a few reasons:
>
> - the file name parsing code assumes ASCII.
> - the code has to guess the case of the pair file.  ex, if you provide foo.HDR, it has to guess either .img or .IMG, and this may succeed or fail depending if the file system is case sensitive or not.  To say nothing of users maybe having mixed case names like "foo.imG".
> - OSes these days often sandbox access to the file system and this guessing around of paths can cause sandbox violations (which could be merely warnings or errors depending on OS).
>
>I'd like to propose new API for such file readers, specifically that clients can pass the path to *both* files.  Then no fragile is guessing is needed.  We wouldn't need to change existing API, merely add new ones.
>
>But before starting, I'd like to know if this would be accepted...
>
>Thanks,
>
>--
>____________________________________________________________
>Sean McBride, B. Eng                 sean at rogue-research.com
>Rogue Research                        www.rogue-research.com
>Mac Software Developer              Montréal, Québec, Canada
>
>
>_______________________________________________
>Powered by www.kitware.com
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Kitware offers ITK Training Courses, for more information visit:
>http://kitware.com/products/protraining.php
>
>Please keep messages on-topic and check the ITK FAQ at:
>http://www.itk.org/Wiki/ITK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/insight-developers


________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________