In order to allow for the delivery of context-sensitive services via an SFX-inspired framework, information resources must achieve the following:
- Implementation of a technique to make the resource understand the difference between a user that has access to a service component that can deliver context-sensitive services; and a user that does not. This document describes the CookiePusher mechanism as a pragmatic solution to this problem.
- For users with access to a service component, provide an OpenURL for each metadata-object. The OpenURL document describes its syntax.
1. Recognizing a user who wants context-sensitive services
In this document, the CookiePusher is described, as one of many mechanisms in which problem (1) can be addressed. Inclusion of the location of a service component in a registered user-profile can— for instance— be another way to deal with the problem. Yet another mechanism would be to keep a table that links IP addresses to URLs of service components. It is the information provider, who wants to allow for context-sensitive services for his information resources, who will decide how problem (1) is best addressed in his environment. The CookiePusher has proven to be an elegant approach that causes a minimal overhead for the information provider. Therefore, it is presented here.
2. The CookiePusher
The CookiePusher offers a pragmatic solution whereby an information resource can be dynamically notified about the existence and the location of a service component— such as the SFX server— that accepts an OpenURL as input. From the information contained in that OpenURL, the service component will be able to deliver context-sensitive services to the end user. The knowledge of the existence and of the location of the user's service component is essential for the information resource. It enables the resource:
- To include the OpenURL if the user has access to an OpenURL-compliant service component, and to point the OpenURL to the appropriate URL— the BASE-URL— of the service component (see OpenURL document); and
- To not include an OpenURL if the user does not have access to an OpenURL-compliant service component;
The idea underlying the solution is that a connection to an information resource is not done directly. Rather than going directly to the target-URL in that information resource, a detour is taken via a script that is installed in the same domain as the information resource. That script— the CookiePusher— takes as input some parameters, two of which are essential for the functioning of the solution:
- BASE-URL: the BASE-URL of the institutional OpenURL-compliant service-component eg. the SFX-server (see OpenURL document);
- Redirect: the desired target-URL in the information resource.
To use the CookiePusher mechanism, a simple adaptation at the side of the information resource is required, as well as at the side of the institution that runs the OpenURL-compliant service component and that accesses the information resource.
2.1. Adaptation of the information resource
The CookiePusher script is installed in the domain of the information resource. Whenever a user of the information resource targets the CookiePusher, the information resource will be able to detect the following:
- The location of the user's OpenURL-compliant service component, read from the BASE-URL parameter of the URL by which the user connects;
- The URL within the information system, to which the user wants to connect, read from the Redirect parameter of the URL by which the user connects.
Based on the first of the above, the information resource can take the steps it feels are most appropriate to register this specific user-preference. For instance, it can set a long-lasting cookie in the user's browser, containing the BASE-URL of the user's service component. This will enable the information resource to detect the user's preference from the browser, during all future visits. This technique has been used with success in many different environments, and the name CookiePusher is actually derived from this approach. It is also the approach shown in the sample CookiePusher script in Table 1. But the information system does not necessarily have to transform the knowledge of the BASE-URL of a user's service component into a cookie. It can add the information to other session-related information, it can store it in the user's profile, ... Basically, it should do whatever is most appropriate to consistently relate a user with his/her service component in a long lasting manner.
Parameters expressing preferences of the institution, other than BASE-URL and Redirect, can potentially be provided via the CookiePusher mechanism. However, during the initial deployment of the first existing OpenURL-compliant service component the Ex Libris SFX solution— , it is proposed to agree on these preferences in a hard-coded manner. The information provider is encouraged to support the following preferences to deal with SFX servers:
- Insertion of an SFX-button in the output of the information resource: For each SFX service component, the clickable image that should be hyperlinked with an OpenURL is always located at BASE-URL/sfx.gif.
- Opening of the SFX-menu-screen: Clicking the SFX-button (the OpenURL) opens a browser window with the following properties:
- window name = SFXmenu
- location = no
- status = yes
- menubar = no
- scrollbar = yes
- resizable = yes
- width = 460
- height = 420
2.2. Adaptation at the end of the institution using an OpenURL-compliant service component
If an institution's information resource installed the CookiePusher script, as a means to detect the institution's preferences regarding an OpenURL-compliant service component, than the institution must make sure it connects its users to that resource via its CookiePusher. Obviously, this has to be done for all information resources that have implemented the CookiePusher script. There are several ways in which an institution can do this. For instance:
- Enhancement of the institutional menu-system, so that it points at the information resource's CookiePusher script rather than to its start-up URL. Table 2 shows how an institution can use this technique and insert a URL in its menu system that targets an information system via its CookiePusher.
- Creation of a special HTML page to which the users— who want to take advantage of the institutional service component— are asked to connect. Connecting to this page will register the location of the user's service component in all the information resources that use the CookiePusher. For each information resource, this HTML page should contain a link to an image that is available at the information resource's site. This link may not be a direct one, but rather one that connects to the image via the resource's CookiePusher. Table 3 shows how an institution can use this technique to create an HTML page that connects to the CookiePushers of all their OpenURL-aware resources.
Table 1: A sample CookiePusher script
# Version: $Id: pushcookie.cgi,v 1.1 2000/04/05 12:03:51 sfx Exp $
# Authors: Patrick Hochstenbach, <Patrick.Hochstenbach@rug.ac.be>
my $cookie_path = '/';
my $cookie_expires = '+6M'; # Expires in 6 months
my $query = new CGI;
my $BASE_URL = $query->param('BASE-URL');
my $Redirect = $query->param('Redirect');
my $cookie = $query->cookie(
-name => 'user-OpenURL',
-value => $BASE_URL,
-path => $cookie_path,
-expires => $cookie_expires,
-uri => $Redirect,
-cookie => $cookie
Table 2 : The URL to connect to an information resource via its CookiePusher
If an institution's OpenURL-aware service component is located at:
If the URL used in the institution's menu-system to connect to an information resource is:
If this information resource's CookiePusher is at:
Than, registration of the location of the service component for a certain user, within the information resource is achieved by editing the institution's menu-system, changing the URL to:
In reality, this URL must be Escape encoded:
Table 3: Creating a single HTML page that connects to all CookiePushers
If an institution's OpenURL-aware service component is located at:
If the institution has access to two information resources that have installed a CookiePusher:
- CookiePusher for resource 1 is at http://www.info.com/cgi-bin/pushcookie.cgi
- CookiePusher for resource 2 is at http://www.moreinfo.com/cgi-bin/cookieset.cgi
Then, the installation should locate a readily accessible an image in each of those information resources, for instance:
- For resource 1 at http://www.info.com/images/info.gif
- For resource 2 at http://www.moreinfo.com/gifs/welcome.gif
Than, registration of the location of the service component for a certain user, within both information resources can be achieved by creating a HTML page that contains the following lines:
<img src = "http://www.info.com/cgi-bin/pushcookie.cgi?
<img src = "http://www.moreinfo.com/cgi-bin/cookieset.cgi?
Again, these URLs must be Escape encoded.