Changes

:for step-1, We use CUPS. The API has a nice array of functions, one of which is to get the printer's name (the cups-pdf virtual printer).And print our file as a PDF in the datastore. Which is pretty much the same for saving as PDF, or sending to moodle.(in the latter we just dont display it, in the former we do)  

:For step-1, We use CUPS. The API has a nice array of functions, one of which is to get the printer's name (the cups-pdf virtual printer).And print our file as a PDF in the datastore. Which is pretty much the same for saving as PDF, or sending to moodle.(in the latter we just dont display it, in the former we do)  

:For the sake of our python convenience we will be using a python wrapper to cups, pycups. The print objects will have metadata attached to them through the sugar datastore API.  

:For the sake of our python convenience we will be using a python wrapper to cups, pycups. The print objects will have metadata attached to them through the sugar datastore API.  

:For the second part of it when ever the print page url is accessed, we make browse communicate with the moodle print queue through xmlrpclib to get the queue details, and upload that many slots (as the number of slots will also be dependent on the print queue through a php trick). This would mean a rainbow hack so that browse can communicate with journal without a dialog (Or a simpler way will be to bypass the dialog automatically). The execution part of this will take place dynamically as soon as the user requests the print page. And also, once the pdf is read, it is destroyed.

:For the second part of it when ever the print page url is accessed, we make browse communicate with the moodle print queue through xmlrpclib to get the queue details, and upload that many slots (as the number of slots will also be dependent on the print queue through a php trick). This would mean a rainbow hack so that browse can communicate with journal without a dialog (Or a simpler way will be to bypass the dialog automatically). The execution part of this will take place dynamically as soon as the user requests the print page. And also, once the pdf is read, it is destroyed.

:for step-2, We will be using the interface already created, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests for his group.The approve button will initiate shell commands to send the particular file to a network printer through CUPS installed on the server.This can again be achieved through hacking into moodle and understanding how notifications are sent to the students from teacher. The notifications would be relating to whether the teacher has approved or disapproved the print.  

:For step-2, We will be using the interface already created, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests for his group.The approve button will initiate shell commands to send the particular file to a network printer through CUPS installed on the server.This can again be achieved through hacking into moodle and understanding how notifications are sent to the students from teacher. The notifications would be relating to whether the teacher has approved or disapproved the print.  

:The moodle part can be achieved through hacking the already existing plugin [http://docs.moodle.org/en/Upload_a_single_file_assignment] and looking into the moodle API and plugin documentation. From my research so far, moodle has most of all the low level details already existing within the moodle libraries. Even $_GET $_POST methods are abstracted into simpler functions.

:The moodle part can be achieved through hacking the already existing plugin [http://docs.moodle.org/en/Upload_a_single_file_assignment] and looking into the moodle API and plugin documentation. From my research so far, moodle has most of all the low level details already existing within the moodle libraries. Even $_GET $_POST methods are abstracted into simpler functions.

:for step-3, no new code is required; a few more dependencies are required, which wont exceed 16mb. We will be including print directly (usb) as an option under the item's right click menu too. This will have the same code as print to pdf for the most part, but will have added code to select a new default printer.

:For step-3, no new code is required; a few more dependencies are required, which wont exceed 16mb. We will be including print directly (usb) as an option under the item's right click menu too. This will have the same code as print to pdf for the most part, but will have added code to select a new default printer.

:''Is there a disadvantage in relying upon moodle for network printing?''

:''Is there a disadvantage in relying upon moodle for network printing?''