Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upNo Profile Mode - issues and questions. #375
Comments
This comment has been minimized.
This comment has been minimized.
|
The only approaches I can see to errors subsequent to the initial identification are:
Note: this issue surfaces when we identify an archival format - and record the result, then later encounter an error processing the archival format. The database handler updates the original entry to indicate an error. Obviously, you can't go back and correct a row previously written to standard out or a file. |
This comment has been minimized.
This comment has been minimized.
Yes! It would be great to have consistent results with CLI (no profile) and GUI DROID. See also #224 which I think is related. |
This comment has been minimized.
This comment has been minimized.
|
I also would have interested in seeing consistency between the two versions. I would first want to know how this would affect our enterprise installation of Rosetta and how it implements DROID. I believe it uses the CLI version, but also has added a way to set the Max Byte Scan size setting. It would also allow us to add the ability to scan more archival formats within the Rosetta preservation system. |
The No Profile mode in the command line project suffers from multiple issues.
Origin
The original idea of no profile mode was to support outputting droid metadata without the overhead of a database. If the results were just going to go to the standard out, or a file, then there was no need to record them in a database as well.
Implementation
A decision was made to re-implement all the core identification and archive handling in the command line project for the no profile mode. This was a short term decision made due to some annoying incompatibilities (filters being one). At the time there was only zip, gz and tar archive handling.
Outcomes
The result of this is that there is a considerable maintenance burden imposed by the no profile mode, as the archive handling must be re-implemented every time a new type is added. In fact, the implementations provided by no profile mode are much less capable than the ones already available in the main droid projects (they can't handle nested archives for the most part).
Identification also suffers, as the logic doesn't match what is available in the rest of DROID, and results suffer as very little metadata is outputted in this mode (just filename and puid).
Original design
In the original design, the idea of no profile mode was that it should use all the same profile machinery, but just plug in a csv output ResultsHandler (whether to standard out or a file), instead of the database results handler.
Questions
Note: I see there is an issue with no-profile-mode filenames containing commas here: #34 This would be fixed by using a CSV output format for droid metadata. The idea would be that no profile mode could output data essentially the same as if we had profiled with a database, and then performed an export. The output could still be given in the current format for backwards compatibility reasons.