How this cartridge resolves URLS


The 'real' OWA has it easy. Every request it receives will either be a stored procedure call OR it will be an error. OWA can do stored procedures, period.

This cartridge on the other hand is capable of handling:

Therefore, the way in which we resolve a URL is a little different. The general form of a URL is:

	http://YourHost/DCDName/owa/Request
This is true for this cartridge as well as the OWA cartridge. Using OWA however would fix the string 'owa' to be a constant and 'Request' to be the name of a stored procedure. With this cartridge

So, onto how we resolve URLS.

http://yourHost/DCDName/owa/Request

We will start with a service type of OWA as shown here. This is the most generic form of the URL and will use the following algorithm to decide what it will return:
	Attempt to describe 'Request' as a stored procedure

	if ( describe fails AND using Client Authentication ) 
	then
		Attempt to describe DCD_userName.Request as a stored procedure
	end if

	If both describes FAILED
	then
		Look in the table DCD_userName.IMAGE for a row with a primary 
		key = 'Request'

		if No Such Row Exists
		then
			translate 'Request' using the virtual-physical mappings 
			found in the svXXXX.cfg file.

			if No such file Exists
			then
				if ( file ends in .gz AND file without .gz exists )
					return compressed version of file
				else
					return FAILURE (404 - URL Not found)
				end if;
			else
				return OWASSI processed file
			end if;
		else
			return that ROW from DCD_userName.Image
		end if
	else
		execute that procedure and return the results
	end if
In short, http://youHost/DCDName/owa/request will first try to find a stored procedure 'Request' or DCDName.Request, then it will look in the DCDName.Image table for a row that matches 'Request' and lastly it will try the OS file system.

So this begs the question, what if I KNOW that what I want is a row from the IMAGE table. Can I skip over those two describes? The answer is yes.

http://yourHost/DCDName/owai/Request

http://yourHost/DCDName/owaigz/Request

This form of the URL, using owai, or owaigz instead of owa, will cause the following logic to be followed to resolve the name:
	select * from DCD_userName.IMAGE where name = 'Request'

	if ( no_data_found ) then
		return 404 - No Such URL
	else
		if ( service type = 'owaigz' ) 
			compress and return data
		else
			return data
		end if;
	end if
As you can see, if you KNOW you are returning an image, you can avoid all of the overhead of trying to find a stored procedure and then looking in the file system.

This is also useful if you have a stored procedure named "filename.pdf" (a stored procedure named pdf in a package called filename), an IMAGE in the IMAGE table named filename.pdf, and a file in the OS named filename.pdf. You can get the one you want by using owai[gz] instead of owa.

Now this begs the question, what if what I want is a Database Server Side Include? Can I get it without going through the long algorithm for resolving names? Yes...

http://yourHost/DCDName/owassi/Request

http://yourHost/DCDName/owassi/Request.gz

The above URL will use the following algorithm to resolve the requested data:
	translate 'Request' using the virtual-physical mappings found in the svXXXX.cfg file.

	if No such file Exists
	then
		if ( file ends in .gz and file without .gz extension exists )
			compress and return that file
		else
			return FAILURE (404 - URL Not found)
		end if
	else
		return OWASSI processed file
	end if;
So what is

http://yourHost/DCDName/owaup/Request

This form of the URL is a leftover from when the file upload capability was a separate CGI-BIN application called owaup (OWA Upload). It is provided for compatability with existing applications that used it. It is equivalent to using owa, the same algorithm will be used to resolve names as is used for owa.

Recommendations

You can use owa for all of the above (regular OWA calls, file downloads, Database Server Side Includes). Attempting to describe a non-existent procedure takes about 1/100 of a second on my Sparc-20. Using owa to retrieve a file that is in the IMAGE table (as opposed to using owai in the URL) will add about 2/100 of a second to the response time. If you don't believe me, see how to set timed statistics on for this cartridge. You'll see the timings for the DESC in there and can judge for youself.

For those that feel the need for speed..... Use owai for images, use owassi for database Server Side Includes. You'll save a couple hundredth's of a second. Supply an owaigz link for blobs in your database that people can download over a slow line. It will chew up CPU time on your server but can significantly reduce the time it takes to download the file for your user.