pcb

Bug #733635
Comment #3

Comment 3 for bug 733635

Revision history for this message

KaiMartin (kmk-familieknaak) wrote on 2011-07-01:

I don't see, why number 3) to 5) are blocked by imminent plans to change the format. Let me go thru them again:

/------------------------------------
If for any reason, the file given on the command line cannot be opened right away:

3) Do not automatically open a new layout.
--> provide a default code path in case of failures/warnings, etc.
This code path does not have to know, what exactly went wrong for what reason. Its task is to help the user gracefully deal with the failure. So it should provide all information, that can be gathered automatically. E.g. the blob of layout data that triggered the failure.

4) Ask the user what to do:
   a) open the PCB anyway
   b) present a help message that gives details on the change of format
   c) quit
--> this is what the default code path should do. b) is only applicable for special cases, where the problem is known at compile time. An example would be backward-incompatible changes in file format. That is, the new version of PCB is known to fail on layout files written by an old version of PCB. If the failure is due to some forward-incompatible format changes, the parser can of course not know what happened. In this case, it still can give the offending lines. This would provide a way for users to ask sensible questions on the mailing list.

5) Make the parser more forgiving. E.g. issue warnings when it hits syntax, it does not understand but don't completely quit working. Yes, this is a pain to implement. But it will cushion the strain on users when pcb format will be bumped seriously.
--> Parser functions should only return ok, if a blob could be processed successfully. Else, it should report a failure to the caller. The caller should then refer to the default code path mentioned above.

IMHO, these tasks, in particular, the last one, should be tackled before a major change of format. This is parser basics, that is obviously not in good shape in current code. The project just got away with it, because there were no major format bumps for a long time.

---<)kaimartin(>---

I don't see, why number 3) to 5) are blocked by imminent plans to change the format. Let me go thru them again:

/------------------------------------
If for any reason, the file given on the command line cannot be opened right away:
 
3) Do not automatically open a new layout.
--> provide a default code path in case of failures/warnings, etc.
This code path does not have to know, what exactly went wrong for what reason. Its task is to help the user gracefully deal with the failure. So it should provide all information, that can be gathered automatically. E.g. the blob of layout data that triggered the failure.

IMHO, these tasks, in particular, the last one, should be tackled before a major change of format.  This is parser basics, that is obviously not in good shape in current code. The project just got away with it, because there were no major format bumps for a long time.

---<)kaimartin(>---