laeubi
commented
5 years ago Another Use-Case are Process methods, each entry could produce info/error messages, but all are presented as a flat list.
Closed laeubi closed 2 years ago
laeubi
commented
5 years ago Another Use-Case are Process methods, each entry could produce info/error messages, but all are presented as a flat list.
eselmeister
commented
5 years ago Yes, that's an issue. It works so far but is suboptimal. Unfortunately, the measurement data is stored in text and binary files. Some do have an extension. Some have the same extension, but are of different encoding or of different type, see CDF. Some have a unique magic code, most of them don't have it. Some measurements are stored in a folder, some in two or three files ... it's a mess.
That why the data converter tries to guess the format.
Let's improve things here. But I would like to be involved, as this format issues could get really tricky.
Am 15.10.19 um 15:18 schrieb Christoph Läubrich:
Currently Messages in a MessageConsumer are flat. This works as long as we take only a single call into account, but if more attempts are made, it is not suitable. One example is when trying to read a certain file as a chromatogram, many readers are queried until a suitable format is found. A reader might now return an error (e.g. invalid characters in a csv file), then the next is tried and so on, at the end no-one could read and then a generic error (no converter found) is returned. Now the caller knows that something has gone wrong, and can report that it was somewhat not possible to read that file, but the user is lost now as he has no way to find the underlying error (invalid character).
Wit a hierarchy of consumers the following would be possible:
- the reader generates a generic error-object (no converter available)
- it then creates a child, with the name of the reader (e.g. CSV)
- the reader can now read the file and report the error to the child
- now other readers are tries (everyone gets its own child)
- if any reader can read the child is returned
- if no reader can (successfully) read the error object is returned, and the user can inspect the different errors of converters to find out why the reader can't read the file
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/eclipse/chemclipse/issues/74?email_source=notifications&email_token=AAFHUTZA3TCTDXJCW3AHL4TQOW7JPA5CNFSM4JA4PYTKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HR33OQQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHUT64TF7PSUDUXKYAUDTQOW7JPANCNFSM4JA4PYTA.
--
OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@openchrom.net » http://www.openchrom.netIts only about Feedback-Messages, Importers/Readers won't notice any significant change.
Currently Messages in a MessageConsumer are flat. This works as long as we take only a single call into account, but if more attempts are made, it is not suitable. One example is when trying to read a certain file as a chromatogram, many readers are queried until a suitable format is found. A reader might now return an error (e.g. invalid characters in a csv file), then the next is tried and so on, at the end no-one could read and then a generic error (no converter found) is returned. Now the caller knows that something has gone wrong, and can report that it was somewhat not possible to read that file, but the user is lost now as he has no way to find the underlying error (invalid character).
Wit a hierarchy of consumers the following would be possible: