200
edits
Changes
no edit summary
=WARNING: This is Outdated Documentation!!!!=
'''THIS IS OUTDATED DOCUMENTATION''' See new Umlaut documentation at http://github.com/team-umlaut/umlaut/wiki
---------
=Setting up the Request and it's context=
Part of [[Umlaut Technical Overview]]
==OpenURL parsing and storing==
In understanding Umlaut, it's helpful to understand a bit about the nature of an [[OpenURL]], including that an OpenURL is composed of several entities or groupings of metadata. Jeff Young's [http://q6.oclc.org/2006/08/welcome_1.html Q6 blog] includes one good explanation of the six OpenURL entities.
Two sets of classes are involved in dealing with OpenURLs in Umlaut. The ropenurl library is generally used to parse OpenURLs. However, Umlaut serializes OpenURLs to it's own ActiveRecord classes--[http://umlaut.rubyforge.org/api/files/app/models/request_rb.html Request], to represent an incoming OpenURL request, and some constituent data in [http://umlaut.rubyforge.org/api/files/app/models/referent_rb.html Referrent], [http://umlaut.rubyforge.org/api/files/app/models/referent_value_rb.html Referent Value], and [http://umlaut.rubyforge.org/api/files/app/models/referrer_rb.html Referrer].
Once the OpenURL is parsed with the ropenurl library, the data is stored in these internal Umlaut classes, which are generally used subsequently to deal with the request data.
A bit confusingly, Umlaut's own Request (an ActiveRecord which represents a parsed OpenURL request, and other persistent state related to Umlaut's handling of that OpenURL request) should not be confused with the Rails ActionController::Request class (which represents the complete details of the current 'raw' HTTP request, and is not stored persistently in the db).
The point of this re-use of Request objects is that if the user presses the browser reload button, the app should be connected with the same already created request--allowing the same already generated responses to be used, among other things. This also allows the user to click on various Umlaut functions and keep re-using the same Request. Again, the main reason this is important is to re-use already generated responses instead of re-generating them. This is also important for background service processing.
Cache matching for re-use is based on: Must be from the same session, must be from the same originating IP address, must have the same OpenURL elements (ie, same OpenURL parameters measured by a serialized version (Request#serialized_co_params)) stored in the 'params' attribute of Request.
Alternately, if the request ID is passed in (in query var "umlaut.request_id"), that is used instead of context object element matching. Umlaut often passes requestID internally, to make sure the same request is recovered. If request_id matches, sessions is not required to match--this is intentional to recover the request even if browser isn't returning cookies, thus not connecting to same session.
So there are Services, and they are grouped into Institutions. How do they actually get brought into play to respond to a resolve request? The [http://umlaut.rubyforge.org/api/classes/Collection.html Collection ] object. A Collection keeps track of a bunch of services to be used for a given session.
The resolve index action creates a new Collection based on ip address and other session information. The new Collection will discover which Institutions apply to a user, and which Services belong to that Institution, and file them all by priority. Other Services may be found that do not belong to an Institution, for instance Collection is supposed to identify [[SFX ]] servers for a user's IP addr via the Worldcat Registry, create a Service pointing to that foreign SFX server, and include that in a Collection. Although this functionality may not be working at present.
The Collection is stored in the Session. It is not actually an ActiveRecord, instead it is stored serialized in the Session--along with all it's Services. One catch to this is if you change Service configuration in services.yml, users may still be getting the old configuration from their serialized Collection in their Session. Deleting all Sessions is a good idea to handle this. (Deleting sessions ought not to interfere with anyone's activity in progress, except to uncache certain things).
When the resolve action wants to actually execute services, it goes through each priority level, and asks the Collection for the Services at that priority level.
[[Category: Umlaut]]
