Tuesday, July 31, 2007

How does the CUPS filter work?

Printing in the Unix world is heavily dependent on filters. These are the work horses of the unix printing. Filters are nothing but a program which one data type as input and converts them into another format. Different applications can generate data in different formats. Like a plain text file, Postscript file or an image file. Printers can also support different data types. A postscript printer will not need any filter if the application is generating postscript data. This is how the  print flow looks
Application-> CUPS->Application->CUPS->Filter->CUPS->printer.

1. User clicks on the print button of the application.
2. Application calls CUPS to show the list of printers installed in the system.
3. User selects a printer.
4. Cups reads the PPD file associated with the printer and displays the print options available for that model. If no PPD is available then a default list of options are shown.
5. When user finishes making all the choices, CUPS parses PPD and gets the appropriate postscript commands for the options. Like for duplex command the PPD contains a specific postscript command.
6. If a filter is mentioned in the PPD, cups will try to convert the output data type of the application to the input data type of the filter.
7.How does cups determine the output data type of the application. For this it uses a mime.types file. This file has 2 columns. The 1st column describes the data type/sub type. Like image/jpeg. The 2nd column tells the extension of the file and the hexadecimal code found in the beginning of the file. Like application/x-dvi dvi string(0,<F702>) F7 and 02 shows it is a dvi file.
8. Now it looks into a mime.convs file. This file has 4 entries. Source data type,  output datatype, cost, name of filter.
application/x-dvi application/postscript 50 dvitops
9. The cost determines which path to take to reach the output type if multiple ways are available.
10. The filter takes its input from the argv parameter in the main function.
11. The filter mostly takes it input from the  stdin, but can also take from the a filepath stored in the argv[6] location.


Powered by ScribeFire.

Tuesday, July 24, 2007

What is JSP?

Java Server Pages. (This is a technique to separate static HTML form dynamic by adding tags in the html document).
Is it written in JavaScript? -> No it is HTML + Java
How does a Servlet look -> A Servlet is pure Java code.
How to call a function included in a JAR package in JSP? -> Include the Jar package in the webapps/lib/ folder. And then import the package name, which is there in the top line of the Java source file in the JSP file. You can now use the function in the Java classes.

Monday, July 23, 2007

What is WSDL and why do we need it?

If WSDL is the web description language of a method, then why do not we define it the function in english. What is the advantage of having a structured form for the WSDL?
Sol-> The reason WSDL is not in english and is in XML is so that other programs can read this XML and generate function prototypes for developers. For example, microsoft provides WSDPrint.wsdl file which defines the functions for sending a print job to a webservice enabled printer. Programs like gSoap can read this WSDL and then create function stubs like CreatePrintJobRequest() and SendPrintJobRequest() with all the necessary parameters. The developer then just needs to implement the reuired portions inside the function and complete the implementation. A Java developer can also use this WSDL to create Java function stubs and so this gives a lot of freedom for the language of implementation.


Powered by ScribeFire.

What is the Tomcat server and why do we need it?

A Tomcat server is a container for Java written code. This code can be called servlets or JSP (Java server pages). What the server does is takes this Java code, compiles it into .class files and then displays this to the end user.
What is a Servlet?
A servlet is a piece of Java code which generates a HTML page. This code resides on the server side and depending on the options selected by the user, different parameters are sent to the servlet. The servlet basically has lot of print statements to generate the HTML code dynamically.
JSP is just a easier way to do the same thing what the servlet does. JSP has tags which can be used to embed the Java code inside HTML. The Tomcat server compiles the Java code and makes HTML out of it dynamically. This saves the developer to write lot of print statements to generate the HTML like head, body, title etc.