Compatibility system

[florian]

Because Casio provide different calculators, we must manage compatibility problems.

Casetta should be able to generate a compatibility report with, for each data:

• if this data can be transferred to the target model or not (errors)
• if this data will be fully managed by the target model or not (warnings)
• if this data can be changed to be compatible (and Casetta should provide to make those change automatically).

[florian]

(Xion345 implementation idea from the mailing-list)

About the implementation, I have the beginning of an idea. It would use the new object models of cas.py. In this e-mail (  http://listengine.tuxfamily.org/lists.tuxfamily.org/casetta/2007/08/msg00002.html ), I said about the file devices_serial.py In send_data() function :

raw_data_list = [data.raw_data[0:1028],

data.raw_data[1028:2056], data.raw_data[2056:3084], data.raw_data[3084:4112]]

elif data.class == datacls.Matrix or data.class == datacls.List or data.class == datacls.SimlEquationMatrix? or data.class == datacls.PolyEquationMatrix?:

raw_data_list = data.get_raw_data_list()

else:

raw_data_list = [data.raw_data]

I would like to replace this by : raw_data_list = data.get_raw_data_list(). This means each Transferable object in cas.py, should have a method who returns a list of data to be transferred even if this list contains only one element

I think each get_raw_data_list method (which is called before any transfer) could call another method named is_valid which would take the model of calculator in argument and raise errors. For example for a program :

class TransferableProgram?(datacls.Program):

.... def is_valid(self, calculator_model):

if calculator_model != "G100" and len(self.name):

raise TooLongNameError?

if calculator_model == "G25":

for line in self.get_text():

raise

class TransferableList?(datacls.List):

.... def is_valid(self, calculator_model):

if calculator_model == "G25":

raise ListNotAvailable?

An then casetta_cli and gasetta could provide fixes using try: except blocks. Or maybe we should directly include a method to do the various fixes inside the objects. This implementation has advantages : quite easy to implement, ability to make completely different tests for any data_type and drawbacks : the method is_valid may be enormous for some data_types such as programs, it is not really "clean" as the compatibility test suite is not located is a specific module, and we cannot distinguish fatal, major errors and warnings. For warnings maybe just a return -1, "Your picture uses colors, I may not be displayed correctly." is enough.

[florian]

I think it could be better to have a strict separation between transfers and compatibility check: the casetta python package provides both, and it's the interface choice to make a test before a transfer. I think it would be better if the compatibility system return an object like that:

report.has_error #return if we can transfer the file or not report.has_warning #return if we should display some warnings for data in my_file:

report[data].has_error #return if this data has raised an error report[data].has_warning #return if the data has raised a warning for error in report[data].errors:

error.summary #informations about the error error.can_be_fixed #return if the error can be fixed error.is_warning #return if the error is a warning error.fix() #return the data fixed

This object should be generated by a module which take:

• For each data, some test functions
• For each casio models, some rules to use with previous functions

It's a detail, but an error.summary property will said that we introduce some end-user text to translate in casetta (for the moment, all end-user messages are in interfaces). Maybe we can make instead an error.id property, with constants for each id, and interfaces will use their messages for each id...