143
edits
Changes
Summer of Code/2009/Print Support (view source)
Revision as of 20:55, 28 March 2009
, 20:55, 28 March 2009→About your project
: (These steps would mean a) moodle print queue, web interface b) (3) a cp activity that bypasses the need to use (2) if you're in Sugar)
: (These steps would mean a) moodle print queue, web interface b) (3) a cp activity that bypasses the need to use (2) if you're in Sugar)
:'''5)''' So we've had a no XO case, similarly we have a no XS case. The simple alternative to this case is to print directly through usb. And this won't be counter productive to the idea of teacher moderated printing, as the printer won't be available for just anyone This is only a quick alternative to the 'save to portable drive and do the printing' method.
:'''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. We will also write code for it to accept copy Mime info from activities .info files (whether a new activity or old)
: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 and mime.conv 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. We will also write code for it to accept copy Mime info from activities .info files (whether a new activity or old)
:for step-2, We use CUPS. The API has a nice array of functions, one of which is to get the printers name (the cups-pdf virtual printer). Since we know the name is CUPS-PDF, we can check it, and print our :file as a PDF to the journal. And the API can be made by generalising the pycups methods and sugar api in general.
:for step-2, We use CUPS. The API has a nice array of functions, one of which is to get the printers name (the cups-pdf virtual printer). Since we know the name is CUPS-PDF, we can check it, and print our :file as a PDF to the journal. And the API can be made by generalising the pycups methods and sugar api in general.
:For b) We will be creating a new print management page in moodle, which accepts at most 3 print requests(the pdfs) from the user at a time until one of them is processed or deleted. We will be :creating a plugin with the FILE_API of moodle( which enables us to do things like uploading client side files, and sending them, and receiving back the files, deleting them) in php, and access the local :to print files, send upload them to the moodle server datastore. I will be taking the already available "upload one file for teacher's review" plugin's code as basis for this. [http://docs.moodle.org/en/Upload_a_single_file_assignment]
:For b) We will be creating a new print management page in moodle, which accepts at most 3 print requests(the pdfs) from the user at a time until one of them is processed or deleted. We will be :creating a plugin with the FILE_API of moodle( which enables us to do things like uploading client side files, and sending them, and receiving back the files, deleting them) in php, and access the local :to print files, send upload them to the moodle server datastore. I will be taking the already available "upload one file for teacher's review" plugin's code as basis for this. [http://docs.moodle.org/en/Upload_a_single_file_assignment]
:for step-4, We will be using the /same plug-in/interface already created/, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests, and the approve :button will initiate shell commands to send the particular file to a network printer.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. And when going with step 3) case a, we would just make moodle talk back to our activity through xmlrpc, and tell the user whether his job has been printed or discarded, and provide a reason why.
:for step-4, We will be using the /same plug-in/interface already created/, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests, and 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. And when going with step 3) case a, we would just make moodle talk back to our activity through xmlrpc, and tell the user whether his job has been printed or discarded, and provide a reason why.
:for step-5, no new code is required, just a slight modification of the cp activity to select the type of printing. A few more dependencies, Which wont exceed 17mb.
:''Is there a disadvantage in relying upon moodle?''
:''Is there a disadvantage in relying upon moodle for network printing?''
:Since the whole concept relies upon network printing, it will be feasible for moodle to coexist with the system on the school server. We will just be adding moodle as a :requirement for printing.
:Since the whole concept relies upon network printing, it will be feasible for moodle to coexist with the system on the school server. We will just be adding moodle as a :requirement for printing.
:'''Key features:'''
:* Will be able to print to any USB printer
:* Will be able to output a print as a PDF
:* Can be extended to include any activities MIME types for PDF printing
:* Includes a local queue, and a teacher queue
:* Has a nice control panel activity that takes care of sending files from activities and locally queueing them
:* CP activity will have the feature to select the type of printing, which will by default be pdf.
:* CP activity communicates directly with moodle data store through XMLrpc.
:* Uses moodle as interface for teacher moderated printing
:* A 3 live/pending jobs at a time queue.
:* Teacher can approve/ disapprove printing from the queue.
:* Student will have status updates in his page and/or in his cp activity.
:* Has a no XO case, no school server case.
:'''Week 1 : '''
:'''Week 1 : '''
:Start writing script which actually configures the network printer server side. Write code which prints to local cups-pdf printer.
:Start writing script which actually configures the network printer server side.
:Write code which prints to any selected printer.
:'''Week 2 : '''
:'''Week 2 : '''
:Finish working on UIs, and append a new printer module(api) to Sugar packages (api) which abstracts a lot of code. Also write code to save to journal for our case 3) b)
:Finish working on UIs, and append a new printer module(api) to Sugar packages (api) which abstracts a lot of code. Also write code to save to journal for our case 3) b)
:Mile stone 1 :'' See to it that the code can print to the pdf virtual printer. Obviously apart from pdf printing others will be disabled. Get mentor and community feedback.
:Mile stone 1 :'' See to it that the code can print to the pdf virtual printer and attached printer. Obviously apart from these both network printing from the XOs will be disabled. Get mentor and community feedback.