Sir Louie will make it possible to build a reading list in the WebLearn (VLE), (based on the Sakai open source platform) by searching for items using the University’s library search interface SOLO, (based on Ex-libris Primo). This concept is based on the existing functionality in the Sakai ‘Citation Helper’ module which allows you to do something similar but using Google Scholar to search for items to add to the list.
The way the Citation Helper works with Google Scholar is that once you create a reading list in the Citation Helper, you have the option to “Search Google Scholar”. Clicking this option pops up new browser window with Google Scholar loaded.
As you search Google Scholar, on each item in the results, in addition to the usual options Google Scholar supports there is an additional ‘Import into Sakai’ (or equivalent wording) link. When the user clicks this, the citation gets saved into the Citation Helper reading list they are working on.
The way this is achieved is that an additional URL parameter is passed to Google Scholar that tell it to both offer the link back to Sakai and which particular Citation Helper reading list items should be added to. For example, a URL could look like this:
http://scholar.google.co.uk/schhp?linkurl_base=http://sakaibrary.lib.indiana.edu/savecite/54e50417-06c8-4076-bbdf-73a1432d6aa0%3Fsakai.session%3D0ebe968f-95de-4e9c-ae76-ca3127d7af96%26&linkurl_id=default
The ‘linkurl_base’ parameter is persisted by Google Scholar throughout your search session – so each time you click a link in the Google Scholar search, it passes the linkurl_base around, so it always knows where to pass any citations you save back to.
When we came to look at achieving a similar functionality with SOLO, we had a challenge – how to tell SOLO that the user needed to see the ‘Import into WebLearn’ link, and how to ensure SOLO was able to pass the citation back to the appropriate Citation Helper list? Having decided that we would use Javascript to add some aspects of functionality to the SOLO interface, what we ideally wanted was a mechanism that:
- Did not require any major modifications to SOLO
- Allowed any stored values to be easily be read by javascript
- Would allow us to display the appropriate link back to WebLearn for a single search session on SOLO
While we considered copying the Google Scholar approach it would have meant significant work to enable SOLO to pass around a new parameter in the URL, and ideally we didn’t want to make significant changes to the system.
We decided to look at more ‘lightweight’ ways of passing this information between the two, otherwise unconnected, systems. The first approach we considered was using a Cookie to store the relevant information. However, WebLearn and SOLO are on different subdomains of *.ox.ac.uk, and we weren’t keen on setting a cookie on the top-level domain, not least because if we were going to offer this development to other sites there was no guarantee that in other situations the Sakai installation in question would be in the same domain as the library system.
We also looked at passing a URL parameter to SOLO which could be immediately written to a cookie at the SOLO end, within the SOLO domain. However, the load balancer that sits in front of SOLO removes any extraneous parameters from the URL before serving up the SOLO search interface to the user. While it would have been possible to investigate this further and see if the cookie could be written by the load balancer page, again this seemed to be getting deeper into changing the system than we wanted, and raised concerns about sustainability and transferability again.
So, having decided Cookies were not going to do the job in this case, we had to start looking at other options. One suggestion was using the browser window.name property to store information. The window.name could be easily set from WebLearn when opening a new window for the SOLO search (simply by including a ‘target’ attribute in the link – e.g. <a target=”WebLearn” href=”http://solo.bodleian.ox.ac.uk”>). The window.name property can easily be read (and if necessary set) using javascript, and of course didn’t require us to make any particular changes to SOLO beyond the javascript we were going to use to display the ‘Import into WebLearn’ link. So the only question remaining was – would it work?
Some research quickly turned up some examples of people using window.name for very similar reasons to the ones that had led us to investigate it. Most notably Thomas Frank has written a javascript that enables the use of window.name not just to store a simple value, but to store all kinds of session variable – see http://www.thomasfrank.se/sessionvars.html for more details. Surprisingly window.name can store several megabytes of information – the limits are imposed by the browser rather than any particular limitation to the property itself, and Opera seems to be the most conservative (and possibly most sensible) limiting window.name to (only!) 2Mb.
Storing session variables in window.name is not without its issues – specifically security is a concern. As window.name isn’t limited to a domain (unlike cookies, and one of the reasons it is useful to us), anything you store in window.name can be read by any other web page. This means clearly you don’t want to store any information that could result in personal or secure information being intercepted. Thomas Frank considers security issues at the bottom of his piece at http://www.thomasfrank.se/sessionvars.html, but for a sceptical view of the use of window.name see http://www.boutell.com/newfaq/creating/scriptpass.html, which describes three ways of passing data between webpages using javascript, including the use of window.name.
We feel reasonably confident that the security issues raised will not impact on us, as we are not passing any personal or secret information around, and so for us window.name looks like the most promising approach to enable WebLearn to pass information to SOLO.
