class room/school server as the print server* <div class="gmail_quote">On Thu, Mar 19, 2009 at 10:11 PM, Vamsi Krishna Davuluri <<a href="mailto:vamsi.davuluri@gmail.com">vamsi.davuluri@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Carol, thanks for replying! Much appreciated! So in a classroom environment, can I assume the classroom server will be acting as the server? The thing is I never got proper input on what I branded obscure. Yes, I agree, if its a classroom environment I'll definitely add permission access and queuing management. Permissions I'd grant as follow: Only the requester and the print server owner can remove the requesters job from the queue, otherwise there is no way to stop the job. Implementation to check match IP address should do the trick, a read in the configuration file, and the originating signal.<div> <div></div><div class="h5"> <div class="gmail_quote">On Thu, Mar 19, 2009 at 10:00 PM, Carol Farlow Lerche <<a href="mailto:cafl@msbit.com" target="_blank">cafl@msbit.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Print queue management and quotas are key to this feature being usable in a classroom/school environment. Consumables are very expensive and kids love to hit print, often without thinking. So providing a way to place print jobs in a "hold for review" status is very important, IMHO, as well as providing a way to look through the queue releasing only the jobs you really want to print. <div class="gmail_quote">2009/3/19 Vamsi Krishna Davuluri <<a href="mailto:vamsi.davuluri@gmail.com" target="_blank">vamsi.davuluri@gmail.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div> Hello! So here is a refined and less abstract approach for the Print Idea. (input credit Luke, Ben, Tomeu) Initial problem: where do we get the cups daemon/server from, and how do we have it working on python since its written in c? solution: The cups daemon would only need to be running on the core distro (add it as a dependency), and we have the amazing pycups bindings which wrap it up, so we can use in our configuration program and other apis which we will discuss. Now, that we have CUPS ready, lets step into implementing it problem 2: Interacting with the CUPS daemon to actually configure the printer solution: Debian has a python version of print-system-configure UI, hacking into the code will yield a decent template for fedora. Which can then be tailored to fit the sugar guidelines. problem 3: Who does the actual printing of the files?! solution: well, again there's these amazing pygtk print modules that take care of it. They make the CUPS API a backend, and work as a decent printing API, they again access the print-system-configure UI(or diving more deeply, the files postscript files (PPD) ) ( I have written a sample printing program demonstrating it on fedora) NOW LETS SUGARIZE THEM! (oh sweet sugar) problem4: We have everything ready but where do we put our print-system-conifguration? solution: we strip the debian (python based) UI, and dress it up with our nice sparkling UIs (the sugar design apis ) and put it in the control panel Here's where I propose an extra credit : Make the configuration An Interactive Wizard, (someone add groovy animations later on, or its on the end list on me) , as we will have to provide a default printer configuration at least once, despite cups having the ability to automatically select the printer. problem5: Okay, okay most of the job is done. Now where do we print from? answer: We print from that one place ofcourse, The Journal! (after all its he uncrowned king bad joke) As it is it is against the bitfrost system for a program to both access the network and the journal at the same time - secuirty constrictions. and also as to see that activity writers dont have to struggle with the print code, we can just see that the print requests are rendered into nice pdfs (CUPS again, we can print to pdfs) with the click of a magical button,store them at a known location and send those 'hit coordinates' and if any metadata by the IPC, and queue them up on journal for print. As an ACK send back a notification to the activity stating, "You have a print job waiting, print it with default settings? or go to journal to edit settings" Remember how i said pygtk can interact with the CUPS settings, well we will implement the relatively important ones in the journal as an option. Extra credit: I've been thinking about this make the school server take in network print requests (feasible/required or not? input please) Obscure stuff: CUPS server, Quota management, and permissions, CUPS server is a background process (hence daemon) which loopsback over the listening ports and ips. CUPS already benefits from a standard print quota management, the secrets of the implementation are in our debian configuration UI. permissions: ( I need input here) print permissions should be of any matter only if its a network assignment as far as i know. So what's the end result:: A nice interactive printer configuration wizard! Minimal work for the activity author! (an addition of 3 modules to print to pdf, but it will be of great value, as the user can present his work in as a pdf within the activity) Journal acting as print dock! pdf printing! And everything sugarized P.S. My actual application will be formal, please dont kill me :P Input Input Input please! Thank You Vamsi Krishna Davuluri </div></div>_______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote></div> -- "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair </blockquote></div> </div></div></blockquote></div>