Changes

:'''4)''' Through moodle the teacher will have a page displaying the contents of the print datastore along with user names attached, and he/she will be able to download them to his remote system, and  check them and approve them for printing if he/she wishes. After his/her approval or disapproval (that is a delete along with an option why) the information is held in the datastore, and the user can view it in the form of history transactions pertaining to his id, and teacher can view a finite list of previous transactions pertaining to all.

:'''4)''' Through moodle the teacher will have a page displaying the contents of the print datastore along with user names attached, and he/she will be able to download them to his remote system, and  check them and approve them for printing if he/she wishes. After his/her approval or disapproval (that is a delete along with an option why) the information is held in the datastore, and the user can view it in the form of history transactions pertaining to his id, and teacher can view a finite list of previous transactions pertaining to all.

:'''In-Depth analysis:'''

:'''In-Depth analysis:'''

:The easiest way to implement step-1 would be to check which mime types exist on the client side in the etc/cups/mime.types file with a simple python method (getAllowableMIMETypes) , and access it with a :python script and compile our sugar shell accordingly. So any mime type non-existent there will have its corresponding activities print button disabled.  

:The easiest way to implement step-1 would be to check which mime types exist on the client side in the etc/cups/mime.types file with a simple python method (getAllowableMIMETypes) , and access it with a :python script and compile our sugar shell accordingly. So any mime type non-existent there will have its corresponding activities print button disabled.