[IGSTK-Developers] Data files for IGSTK tests

[David Gobbi]

Hi Mathieu,

There are several things that make rsync unsuitable:
1) it requires an rsync client, and we don't want to
   make users download yet another package (note that
   ftp or http ability comes built-in with CMake)
2) it requires an rsh or ssh connection, which means
   user/password authentication must be set up on the
   server
3) once the connection is set up, it gives the user
   access to the entire file system on the server
4) it is not a tool that many people are familiar with

Don't get me wrong, I love rsync.  I always use it to
copy my own data back and forth, and I use it to run
nightly off-site backups.

 - David


--- Mathieu Malaterre <mathieu.malaterre at kitware.com>
wrote:

> Hello,
> 
> 	I would really encourage you to use rsync(*). The
> best feature of all 
> is that rsync provide incremental file transfer !
> Therefore it will only 
> download the missing(broken) pieces for the file
> transfer.
> 
> My 2 cents,
> Mathieu
> (*)http://samba.anu.edu.au/rsync/
> 
> David Gobbi wrote:
> > Hi Andinet,
> > 
> > For dashboard testing, CVS is definitely the most
> > convenient because the dasboard machines can just
> > do a "cvs update" every night to grab the newest
> > data.  I think that it would be good to have a
> > couple small data sets (i.e. with just two or
> three
> > slices) in cvs for testing the readers.
> > 
> > It's probably worth looking at the actual file
> sizes
> > involved for full-resolution data sets.
> > 
> > Typical CT: 512kb per slice, 65Mb per data set
> > Typical MR: 128kb per slice, 16Mb per data set
> > Typical Fluoro: 10Mb but highly variable
> > 
> > So even a small collection of full-resolution
> images
> > is going to be close to 100Mb.
> > 
> > My thoughts are that most of the tests can run
> fine
> > with only a partial data set, so we should have
> some
> > partial data sets in CVS for this purpose.  A data
> > directory already exists in CVS:
> IGSTK/Testing/Data
> > 
> > For full data sets, I think that ftp is the best
> > option because we can eventually write scripts
> that
> > will automatically go to the ftp server and get
> > the most recent data sets as part of the "make"
> > process.
> > 
> > With a zip file, it is necessary to grab the
> entire
> > archive even if only a single new file has been
> added.
> > 
> > What is DSpace?
> > 
> >  - David
> > 
> > 
> > --- Andinet Enquobahrie <andinet.enqu at kitware.com>
> > wrote:
> > 
> > 
> >>Hi all,
> >>
> >>I would like to bring up the discussion of how we
> >>should store data 
> >>files used for IGSTK tests.  This is an important
> >>issue because of  
> >>large size CT scans and other modalities that we
> >>will be using for 
> >>testing the toolkit and the demo applications.
> Luis
> >>and I had a 
> >>discussion on this topic yesterday and we
> >>brainstormed the following 
> >>options.
> >>
> >>1) CVS data module
> >>
> >>Caveat: CVS has been reported to have problems
> with
> >>very large size 
> >>binary data.
> >>
> >>2) Downloadable tar/zip data file ( similar to
> VTK)
> >>
> >>2) Dedicated FTP server
> >>
> >>4) DSpace
> >>
> >>Any suggestions?
> >>
> >>-Andinet
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>IGSTK-Developers mailing list
> >>IGSTK-Developers at public.kitware.com
> >>
> > 
> >
>
http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
> > 
> > 
> > _______________________________________________
> > IGSTK-Developers mailing list
> > IGSTK-Developers at public.kitware.com
> >
>
http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
> > 
> 
>