#110 Different I/O implementations to handle all output format versions

[Marek Otahal, CTU Prague]

There are already 2 output format versions:
-old .dat
-actual .aedat
(and in #108, #109 2 more are suggested)
- .csv
- .raw

Each of these formats should have its implementation (so we can use all of them), basically extending from AEFileOutputStream and
-rewriting constants (header info, ..)
-reimplementing specific methods (writeInt(), writeByte(), ..)
-similar of input: AEFileInputStream should exist

[Luca Longinotti]

AEFileInputStream already exists. The abstractions for this should be there.
While I'm not against alternative output formats, as I've stated in other tickets, I believe the overhead of text formats to not be worth the effort. Decoding routines for DVS and DAVIS exist for Matlab already. I don't know about the status for Python. Though writing a function that takes the 8 byte chunks of AEDAT files and gives you back (ts,x,y,pol) is very easy. All DAVIS have the same format for that.

[Marek Otahal, CTU Prague]

on new output formats...
Tobi: "If you want to implement this, implement as a private EventFilter for now. " and "do NOT break current default format!"

Ok, how about this approach (using multiple implementations)?
-It's a clean OOP approach,
-current format (.aedat) stays the default,
-new variations easily possible (.csv,.raw)
-one usecase I had on mind was a conversion utility between these formats

[Marek Otahal, CTU Prague]

hi Luca,

thanks, sorry, I've commented before your post arrived..

[Luca Longinotti]

Well, the implementation as event filter is probably easier. Adding new file formats is easy in theory, but in practice integrating them correctly into the GUI and everything may prove quite a bit of work.
On the topic of converters, if we simply do one AEDAT->CSV converter, that would kinda make all of this a moot point, no? AEDAT is still a far faster format to write out to disk, and if anybody needs to really use CSV to analyze the output, they can just convert it. Again, not entirely sure why one would want to do that. While I agree the current output format isn't perfect (and we're working on that), I also don't see where it is so complex as to make it impossible to parse.