From m.e.phillips at durham.ac.uk Mon Nov 7 11:11:49 2011 From: m.e.phillips at durham.ac.uk (PHILLIPS M.E.) Date: Mon, 7 Nov 2011 16:11:49 -0000 Subject: [Umlaut-general] Progress on connecting WebBridge In-Reply-To: <4EB7F5CC.8010804@jhu.edu> References: <1F5DB00D61AF1A479A6F8572FAC9ED8002E90CDA@DURMAIL4.mds.ad.dur.ac.uk> <4EB7F5CC.8010804@jhu.edu> Message-ID: <1F5DB00D61AF1A479A6F8572FAC9ED8002E91399@DURMAIL4.mds.ad.dur.ac.uk> Hi Jonathan, Thanks for this suggestion: I was not aware of the developments from DOI Central. > There is currently no adapter built in to Umlaut for querying metadata > from a DOI via CrossRef etc. There is a crossref.rb in the service_adaptors directory which had remarks at the top about it not working, so I took that and made it work. It's not as complete as I'd like. All it does at the moment is lookup a DOI and get metadata back, enhancing the referent for any fields not already present. I'm toying with the idea of improving the enhance_referent method in ./app/models/referent.rb to have a ":compare" option which would look at the current referent field value and the proposed referent field value and pick the better one. It should also be possible to look up other metadata via the CrossRef API and pull back the DOI and their metadata. Just a quick report on progress: 1. CrossRef API lookup now working, so things like this (nothing much apart from a DOI) now resolve usefully: http://bit.ly/uBQ4xv 2. CrossRef service adaptor also creates a "related link" to "Look up via DOI" which will help fulfil the conditions for setting a cookie for routing dx.doi.org links via our router. 3. All sorts of other "related links" now appearing courtesy of the WebBridge API. These could do with tidying up a bit! Links to our document delivery forms now functioning too, which is nice. 4. Millennium service adaptor working via Z39.50 but needs a lot more work because we cannot link easily to the correct items. I may decide screen-scraping the OPAC is the better approach, but we're already doing much better than WebBridge. See the following example: http://bit.ly/v4CFFn I'm floundering around a bit not knowing quite what is meant to be put in where with a holding response. Are there any docs I should have read on what is expected for each type of service. 5. Implemented a service adaptor for www.journaltocs.ac.uk See the related link on this example: http://bit.ly/vY8P9s In this example, there is no ISSN in the OpenURL, nor any DOI. The journaltocs API is able to identify the journal and provide the ISSN which we use to enhance the referent, thereby allowing WebBridge, which relies on ISSN and does not do title matching, to find the content. In theory searching for article data is possible too, but only worthwhile for recent ones. They have abstracts in some cases too. It would be good to pull the latest journal articles in from the journaltocs API and provide a panel showing recent articles, but I have not explored how to do this yet. There is a table of contents service type, but I am guessing that's more intended for books? I'm not sure we would want to show the recent articles if it was an article-level OpenURL, but for journal-level it would be very nice. 6. We've re-enabled a lot of the funky service adaptor stuff provided with the software, such as WorldCat identities, Google Books, etc. Some things are still not enabled because we need to go get ourselves some API keys. We had to hack the timeout.rb gem to get the Internet Archive service adaptor working. Perhaps we're on a different version of Ruby 1.8 from what we should be. The amazon.rb source code seems to imply that some services are available without an API key but I could not get that to work. We got an error when HathiTrust was turned on also: I'll try to find time to investigate further. My colleague is also working on an adaptor to connect to CUFTS, so for the moment you will probably see duplicated links from ConneXions and "ImprovedConneXions" as the CUFTS adaptor is pointing at WebBridge for the moment. (And of course if you try the above examples, you may hit on us having just broken something, so come back later if necessary!) So it's all quite exciting, and we're pleased with progress. Matthew -- Matthew Phillips Electronic Systems Librarian, Durham University Durham University Library, Stockton Road, Durham, DH1 3LY +44 (0)191 334 2941 From rochkind at jhu.edu Mon Nov 7 10:14:20 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Mon, 07 Nov 2011 10:14:20 -0500 Subject: [Umlaut-general] Progress on connecting WebBridge In-Reply-To: <1F5DB00D61AF1A479A6F8572FAC9ED8002E90CDA@DURMAIL4.mds.ad.dur.ac.uk> References: <1F5DB00D61AF1A479A6F8572FAC9ED8002E90CDA@DURMAIL4.mds.ad.dur.ac.uk> Message-ID: <4EB7F5CC.8010804@jhu.edu> Sorry, I just remembered you had asked this and I hadn't answered, sorry for the late reply. (And feel free to ping me when I've been ignoring you and you'd like some feedback in the future). There is currently no adapter built in to Umlaut for querying metadata from a DOI via CrossRef etc. However, it does make sense for there to be one, I had considered that there probably ought to be one, and figured i'd write one if I ever needed it. Haven't, since relying on SFX's CrossRef lookups instead. If you were to write such an adapter, I'd suggest _not_ using CrossRef's API -- CrossRef is just one purveyer of DOI's, and CrossRef's API will only look up metadata for CrossRef DOIs. However, DOI central itself recently introduced an HTTP content negotiation API to do metadata lookups -- at _present_, the DOI con-neg API probably only works for CrossRef API's too, but it has the promise of automatically Just (continuing) Working with DOI's from other sources like DataCite once they integrate into the CrossRef con-neg API. So I'd use that, partially documented here: http://0-www.crossref.org.biblio.eui.eu/CrossTech/2011/04/content_negotiation_for_crossr.html Matt, if you do write such a thing, I'd like to include it in Umlaut core distribution. If you try writing it and end up needing some tips, please ask. Jonathan On 10/21/2011 7:05 AM, PHILLIPS M.E. wrote: > I have a little service adaptor which connects to our home-made > WebBridge API now. If you look at the following example: > > http://bit.ly/pP42PG > > you will see four electronic full text versions of the article. The > names of the resources and the URLs are pulled from our live WebBridge > OpenURL resolver. Is this the first time Umlaut has been hooked up to a > resolver back-end which is not SFX? > > Now for a quick question: > > My WebBridge API does not at present do any CrossRef API lookup for > DOIs. On the whole I would prefer this were handled in Umlaut so that > WebBridge is passed fuller metadata. I see there is a crossref.rb > service adaptor but it says at the top of the code that it is not > working. If I want to go down this road, would adapting this code to > make it work be a good way of going about it? I'd have to make CrossRef > a higher-priority service than WebBridge, I suppose. > > Matthew > From rochkind at jhu.edu Mon Nov 7 14:41:38 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Mon, 07 Nov 2011 14:41:38 -0500 Subject: [Umlaut-general] Progress on connecting WebBridge In-Reply-To: <1F5DB00D61AF1A479A6F8572FAC9ED8002E91399@DURMAIL4.mds.ad.dur.ac.uk> References: <1F5DB00D61AF1A479A6F8572FAC9ED8002E90CDA@DURMAIL4.mds.ad.dur.ac.uk> <4EB7F5CC.8010804@jhu.edu> <1F5DB00D61AF1A479A6F8572FAC9ED8002E91399@DURMAIL4.mds.ad.dur.ac.uk> Message-ID: <4EB83472.7010703@jhu.edu> Great, glad you're making progress. You've done a lot of great stuff, much of which I'm interested in adding to Umlaut core distribution, if you are willing and can release under a compatible open source license. Some comments below. > 1. CrossRef API lookup now working, so things like this (nothing much > apart from a DOI) now resolve usefully: > http://bit.ly/uBQ4xv Awesome, I still think using the dx.doi.org con-neg api is better long-term, but CrossRef API is better than nothing. Would you like to submit this back to Umlaut core, for everyone? > 2. CrossRef service adaptor also creates a "related link" to "Look up > via DOI" which will help fulfil the conditions for setting a cookie for > routing dx.doi.org links via our router. Nice. If submitting back to umlaut core, can you make this configurable? Just turn on or off the 'related link' inclusion would be the basic way. More complicated, one could try to make it more complicatedly configurable so for instance 'related link' is only included if there is no 'full text' available. But for starters, just on/off would be sufficient. > 3. All sorts of other "related links" now appearing courtesy of the > WebBridge API. These could do with tidying up a bit! Links to our > document delivery forms now functioning too, which is nice. Hmm, remind me what WebBridge is. The III link resolver? I suspect this is also something Umlaut would benefit from having submitted back to core? > 4. Millennium service adaptor working via Z39.50 but needs a lot more > work because we cannot link easily to the correct items. I may decide > screen-scraping the OPAC is the better approach, but we're already doing > much better than WebBridge. See the following example: > http://bit.ly/v4CFFn Yeah, interacting with ILS's with poor API's is often the biggest challenge. If/when you arive at something that seems good enough or as good as you can do, then let's add that to Umlaut core too! > I'm floundering around a bit not knowing quite what is meant to be put > in where with a holding response. Are there any docs I should have read > on what is expected for each type of service. Yeah, it's under-documented, sorry. You'll find some basics in comments here: https://github.com/team-umlaut/umlaut/blob/master/app/models/service_response.rb If neccesary, you can also configure your local Umlaut to use an entirely different or custom view template for displaying holdings, using a different set of keys. But ideally that would be avoided, so we have compatibility between holdings fetched from different ILS's, even to the extent using multiple ILS adapters in a single Umlaut response. > 5. Implemented a service adaptor for www.journaltocs.ac.uk See the > related link on this example: > http://bit.ly/vY8P9s Interesting. I hadn't thought of using JournalTOCs for meta-data enhancement like this. Since Umlaut is intended to be used not just for journals/articles, but for anything, you might ideally want to try to be careful to not get a 'false positive' from, say, the name of a _book_ to a journal with the same name. If you think you have that handled, then I'd like this in Umlaut core too! (I have some ideas, all a mess, heh, but I could share them). I _had_ thought of using JournalTOC's to actually fetch the latest published articles for a given journal, as you mention, and display them with self-pointing OpenURLs back to the umlaut installation. I'm definitely interested in that, adn planned to do it myself someday. > My colleague is also working on an adaptor to connect to CUFTS, so for > the moment you will probably see duplicated links from ConneXions and > "ImprovedConneXions" as the CUFTS adaptor is pointing at WebBridge for > the moment. Nice. You've done and are working on a lot of really nice stuff, that would be useful to others than you. If you can seperate it all into seperate general-purpose and configurable umlaut Service adapters (sounds like you might already have proceeded that way), I'm definitely interested in a lot of it being contributed to Umlaut. If you are interested, then let's figure out a way to do that. After some brief code review to make sure the way you're doing it makes sense, I'd be willing to just give you commit rights to Umlaut so you can just commit and maintain this stuff inside the Umlaut repo. (Of course, the rails3 Umlaut 3.0 that I'm working on will also make it easy to distribute such things as gems themselves, but we're not quite there yet, and core useful stuff will probably remain in Umlaut core.) From rochkind at jhu.edu Tue Nov 15 17:30:33 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Tue, 15 Nov 2011 17:30:33 -0500 Subject: [Umlaut-general] services config Message-ID: <4EC2E809.8020401@jhu.edu> I would like to combine the services config that is now in institutions.yml and services.yml into ONE file. Either yaml, or perhaps even just live ruby. Looking something like this: default: services: sfx: display_name: "FindIt @ JH" priority: 3 base_url: http://whatever amazon: priority: c api_key: "whatever" Using ordinary YAML conventions, you can still attach an ID to a hash and reference it later in YAML to include the same service definition in more than one 'institution'. Although I don't think I'll call em 'institutions' anymore, they really don't have any 'institution' functionality attached to them, they're just groups/sets of services. Or perhaps the file should be laid out by 'priority' (which isn't a great name either, it's not about priority, it's about order of execution) to make it easier to see what's what? default: services: 3: sfx: base_url: http://whatever c: amazon: api_key: whatever Any comments? From dale.poulter at Vanderbilt.Edu Wed Nov 16 08:42:03 2011 From: dale.poulter at Vanderbilt.Edu (Poulter, Dale) Date: Wed, 16 Nov 2011 07:42:03 -0600 Subject: [Umlaut-general] services config In-Reply-To: <4EC2E809.8020401@jhu.edu> References: <4EC2E809.8020401@jhu.edu> Message-ID: <7288D49C0448E840B752320350AFA94E01206E1BFC@its-hcwnem03.ds.Vanderbilt.edu> Jonathan, I like the idea of combining the two files, it seems that it would make it easier to configure. As far as the layouts I personally like the first option since I normally look for a service and then attempt to determine the priority and not the other way around. -----Original Message----- From: umlaut-general-bounces at rubyforge.org [mailto:umlaut-general-bounces at rubyforge.org] On Behalf Of Jonathan Rochkind Sent: Tuesday, November 15, 2011 4:31 PM To: umlaut-general at rubyforge.org Subject: [Umlaut-general] services config I would like to combine the services config that is now in institutions.yml and services.yml into ONE file. Either yaml, or perhaps even just live ruby. Looking something like this: default: services: sfx: display_name: "FindIt @ JH" priority: 3 base_url: http://whatever amazon: priority: c api_key: "whatever" Using ordinary YAML conventions, you can still attach an ID to a hash and reference it later in YAML to include the same service definition in more than one 'institution'. Although I don't think I'll call em 'institutions' anymore, they really don't have any 'institution' functionality attached to them, they're just groups/sets of services. Or perhaps the file should be laid out by 'priority' (which isn't a great name either, it's not about priority, it's about order of execution) to make it easier to see what's what? default: services: 3: sfx: base_url: http://whatever c: amazon: api_key: whatever Any comments? _______________________________________________ Umlaut-general mailing list Umlaut-general at rubyforge.org http://rubyforge.org/mailman/listinfo/umlaut-general From m.e.phillips at durham.ac.uk Wed Nov 16 10:19:43 2011 From: m.e.phillips at durham.ac.uk (PHILLIPS M.E.) Date: Wed, 16 Nov 2011 15:19:43 -0000 Subject: [Umlaut-general] services config In-Reply-To: <7288D49C0448E840B752320350AFA94E01206E1BFC@its-hcwnem03.ds.Vanderbilt.edu> References: <4EC2E809.8020401@jhu.edu> <7288D49C0448E840B752320350AFA94E01206E1BFC@its-hcwnem03.ds.Vanderbilt.edu> Message-ID: <1F5DB00D61AF1A479A6F8572FAC9ED80031221EF@DURMAIL4.mds.ad.dur.ac.uk> > I like the idea of combining the two files, it seems that it would make it > easier to configure. As far as the layouts I personally like the first option > since I normally look for a service and then attempt to determine the priority > and not the other way around. I agree. I think it's easier to read that way round. If we want we have the option of manually ordering the file by priority if we so desire, or ordering it by display name or whatever we like. Matthew -- Matthew Phillips Electronic Systems Librarian, Durham University Durham University Library, Stockton Road, Durham, DH1 3LY +44 (0)191 334 2941 From rochkind at jhu.edu Wed Nov 16 13:28:59 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Wed, 16 Nov 2011 13:28:59 -0500 Subject: [Umlaut-general] refactoring warnings Message-ID: <4EC400EB.6050407@jhu.edu> Mostly to Scot. I'm realizing that the refactorings to Umlaut 3.0 to make it a rails engine-style 'gem' instead of a standalone application (along with some other minor refactorings) are going to change the context for a couple not-quite-finished things you were working on -- the auth stuff, and the 'institutions' stuff. The good news it should actually make it a LOT easier to do this sort of thing -- including doing it custom in your local app without it needing to be in Umlaut core, so you can do it just how you want without initially needing to figure out how to generalize. The bad news is it will probably be entirely incompatible with your current half-or-mostly finished work in branches. Sorry! For 'institutions'-type functionality, the basic important facts are that: You will have a local ResolveController in your app (your local code, NOT Umlaut distro source), which gets basic ResolveController functionality via 'include'ing a module from Umlaut. But you'll be able to over-ride methods in your local ResolveController -- combined with moving all 'config' to be accessed from the current controller, this will make it easy for you to surgically over-ride a couple methods to provide custom per-request 'config' or custom per-request list of services, based on whatever logic you want. Umlaut will _probably_ lose any notion of an 'institution' at least for now, in core. It's un-needed complexity for what Umlaut has actually ended up doing. For auth type functionality, it's a bad idea for an engine-style gem to include it's _own_ authentication logic or model. We learned this with Blacklight. Instead, the way to go is to document the conventions/api that the gem (such as Umlaut) expects from auth, and let the local app implement however it wants (including using devise etc if desired, or just doing it homegrown), and as long as it respects those conventions it'll work with Umlaut. Sample conventions would be: * a #login_path helper method that leads to login screen. * a #logout_path helper method that logs the user out * a #current_user method in controller that returns non-nil if and only if there is a logged in user. If non-nil, then it's an object that has a given set of methods on it for looking at attributes, including say: * username * internal_id * groups => array of string user_groups the user is in. (This last one is purely speculative, it's in this area of defining what sorts of attributes Umlaut might want/be-able-to-use in a user model that the actual meat of this convention is, it depends on what the use cases are for stock Umlaut code wanting to know something about the logged in user. Custom local code would of course not be bound by this, and could use whatever custom local user attributes you have.) From std5 at nyu.edu Thu Nov 17 08:58:03 2011 From: std5 at nyu.edu (Scot Dalton) Date: Thu, 17 Nov 2011 08:58:03 -0500 Subject: [Umlaut-general] refactoring warnings In-Reply-To: <4EC400EB.6050407@jhu.edu> References: <4EC400EB.6050407@jhu.edu> Message-ID: <02148C5F-5577-4686-B182-F9BD0D057A4D@nyu.edu> This sounds fine for the most part, especially the authentication stuff which sounds great. And of course it brings up a few of questions. In an earlier message, you indicated that services will still be grouped (by institution). Considering what you say about institutions going away, is this a matter of semantics (i.e. institutions vs. groups) or will services no longer be grouped? From our perspective, this is an undesirable change. Will Umlaut 3.0 still gather services for a given request into a collection based on the groups that are in play for that request? If so, will the logic for gathering services be customizable? The logic for determining groups that are in play that we are hoping for is: 1. All default groups 2. Requested group (currently query string parameter umlaut.institution=RequestedInstitution) 3. Groups in the requestors IP range 4. Groups affiliated with the user Let me know if any of this is unclear. It's still early. Thanks, Scot On Nov 16, 2011, at Nov 16, 1:28 PM, Jonathan Rochkind wrote: > Mostly to Scot. > > I'm realizing that the refactorings to Umlaut 3.0 to make it a rails engine-style 'gem' instead of a standalone application (along with some other minor refactorings) are going to change the context for a couple not-quite-finished things you were working on -- the auth stuff, and the 'institutions' stuff. > > The good news it should actually make it a LOT easier to do this sort of thing -- including doing it custom in your local app without it needing to be in Umlaut core, so you can do it just how you want without initially needing to figure out how to generalize. > > The bad news is it will probably be entirely incompatible with your current half-or-mostly finished work in branches. Sorry! > > For 'institutions'-type functionality, the basic important facts are that: > > You will have a local ResolveController in your app (your local code, NOT Umlaut distro source), which gets basic ResolveController functionality via 'include'ing a module from Umlaut. But you'll be able to over-ride methods in your local ResolveController -- combined with moving all 'config' to be accessed from the current controller, this will make it easy for you to surgically over-ride a couple methods to provide custom per-request 'config' or custom per-request list of services, based on whatever logic you want. > > Umlaut will _probably_ lose any notion of an 'institution' at least for now, in core. It's un-needed complexity for what Umlaut has actually ended up doing. > > > For auth type functionality, it's a bad idea for an engine-style gem to include it's _own_ authentication logic or model. We learned this with Blacklight. Instead, the way to go is to document the conventions/api that the gem (such as Umlaut) expects from auth, and let the local app implement however it wants (including using devise etc if desired, or just doing it homegrown), and as long as it respects those conventions it'll work with Umlaut. Sample conventions would be: > > * a #login_path helper method that leads to login screen. > * a #logout_path helper method that logs the user out > * a #current_user method in controller that returns non-nil if and only if there is a logged in user. If non-nil, then it's an object that has a given set of methods on it for looking at attributes, including say: > * username > * internal_id > * groups => array of string user_groups the user is in. (This last one is purely speculative, it's in this area of defining what sorts of attributes Umlaut might want/be-able-to-use in a user model that the actual meat of this convention is, it depends on what the use cases are for stock Umlaut code wanting to know something about the logged in user. Custom local code would of course not be bound by this, and could use whatever custom local user attributes you have.) > -- Scot Dalton Phone: (212) 998-2674 Web Services Division of Libraries New York University From rochkind at jhu.edu Thu Nov 17 11:13:19 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 17 Nov 2011 11:13:19 -0500 Subject: [Umlaut-general] refactoring warnings In-Reply-To: <02148C5F-5577-4686-B182-F9BD0D057A4D@nyu.edu> References: <4EC400EB.6050407@jhu.edu> <02148C5F-5577-4686-B182-F9BD0D057A4D@nyu.edu> Message-ID: <4EC5329F.6060001@jhu.edu> On 11/17/2011 8:58 AM, Scot Dalton wrote: > This sounds fine for the most part, especially the authentication stuff which sounds great. And of course it brings up a few of questions. > > In an earlier message, you indicated that services will still be grouped (by institution). Considering what you say about institutions going away, is this a matter of semantics (i.e. institutions vs. groups) or will services no longer be grouped? From our perspective, this is an undesirable change. Services will still be grouped, mainly becuase I know you wanted it. However, there will be no built in code for dealing with services other than the 'default' group. Instead, the idea is, there will be hooks for you to write your own local code for determining what services apply to a given request -- since you're writing your own local code, sure, you could pull different service groups out of this same .yml file, with groups other than 'default' -- but you could also take the config for services from wherever you want, it wouldn't need to be this file, it could be a different yml file, or live ruby data structures, or whatever you want. It could be live ruby code that takes the default group and then removes certain services from it and adds other services. Etc. > Will Umlaut 3.0 still gather services for a given request into a collection based on the groups that are in play for that request? If so, will the logic for gathering services be customizable? I am not sure Umlaut _ever_ did this! Umlaut does not have any logic in it to determine what groups/institutions are in play for a given request. I know you were working on that. I got nervous about being able to do that in a way that is actually flexible enough for everyone, but without being a monster. I think the best way to do this, especially in a Rails 3.0 engine environment which makes it somewhat easier, is to allow local custom logic to be written however you want to do this. Of course, if you end up with something that does seem flexible general purpose, it can always be added back into Umlaut, too, no problem! It's just gonna be prob a bit different than it was. Basically, what I'm thinking is there's a method in ResolveController that's called as a before_filter, that sets up the Collection object, passing the list (hash, really) of service configurations into the Collection constructor. The default implementation will simply pass the 'default' group from services.yml. You can over-ride this to provide whatever custom implementation you want -- -- but if there are key general purpose useful things we think should be in there, we can add them (back, or first time) into Umlaut too -- possibly the four things you mentioned ought to be added back in to default implementation, we can do that if we need to. Either way I think this is a more clear structuring of the code that centralizes this logic in one method who's only purpose is setting up the Collection for a request. Right now it's kind of all over the place. Hope that makes sense. If it doesn't work out, we can certainly modify Umlaut yet further. I'm just having to make some choices in trying to get Umlaut 3.0 going out the door, they might not all be the right choices, some might have to be corrected (even before a 3.0 final release), but I'm not able to keep everything just the way it was, some things have got to change. I _think_ what I'm doing will still work out fine for you, we'll see! > The logic for determining groups that are in play that we are hoping for is: > 1. All default groups > 2. Requested group (currently query string parameter umlaut.institution=RequestedInstitution) > 3. Groups in the requestors IP range > 4. Groups affiliated with the user > > Let me know if any of this is unclear. It's still early. > > Thanks, > Scot > > > On Nov 16, 2011, at Nov 16, 1:28 PM, Jonathan Rochkind wrote: > >> Mostly to Scot. >> >> I'm realizing that the refactorings to Umlaut 3.0 to make it a rails engine-style 'gem' instead of a standalone application (along with some other minor refactorings) are going to change the context for a couple not-quite-finished things you were working on -- the auth stuff, and the 'institutions' stuff. >> >> The good news it should actually make it a LOT easier to do this sort of thing -- including doing it custom in your local app without it needing to be in Umlaut core, so you can do it just how you want without initially needing to figure out how to generalize. >> >> The bad news is it will probably be entirely incompatible with your current half-or-mostly finished work in branches. Sorry! >> >> For 'institutions'-type functionality, the basic important facts are that: >> >> You will have a local ResolveController in your app (your local code, NOT Umlaut distro source), which gets basic ResolveController functionality via 'include'ing a module from Umlaut. But you'll be able to over-ride methods in your local ResolveController -- combined with moving all 'config' to be accessed from the current controller, this will make it easy for you to surgically over-ride a couple methods to provide custom per-request 'config' or custom per-request list of services, based on whatever logic you want. >> >> Umlaut will _probably_ lose any notion of an 'institution' at least for now, in core. It's un-needed complexity for what Umlaut has actually ended up doing. >> >> >> For auth type functionality, it's a bad idea for an engine-style gem to include it's _own_ authentication logic or model. We learned this with Blacklight. Instead, the way to go is to document the conventions/api that the gem (such as Umlaut) expects from auth, and let the local app implement however it wants (including using devise etc if desired, or just doing it homegrown), and as long as it respects those conventions it'll work with Umlaut. Sample conventions would be: >> >> * a #login_path helper method that leads to login screen. >> * a #logout_path helper method that logs the user out >> * a #current_user method in controller that returns non-nil if and only if there is a logged in user. If non-nil, then it's an object that has a given set of methods on it for looking at attributes, including say: >> * username >> * internal_id >> * groups => array of string user_groups the user is in. (This last one is purely speculative, it's in this area of defining what sorts of attributes Umlaut might want/be-able-to-use in a user model that the actual meat of this convention is, it depends on what the use cases are for stock Umlaut code wanting to know something about the logged in user. Custom local code would of course not be bound by this, and could use whatever custom local user attributes you have.) >> > > -- > Scot Dalton > Phone: (212) 998-2674 > Web Services > Division of Libraries > New York University > From std5 at nyu.edu Thu Nov 17 13:52:26 2011 From: std5 at nyu.edu (Scot Dalton) Date: Thu, 17 Nov 2011 13:52:26 -0500 Subject: [Umlaut-general] refactoring warnings In-Reply-To: <4EC5329F.6060001@jhu.edu> References: <4EC400EB.6050407@jhu.edu> <02148C5F-5577-4686-B182-F9BD0D057A4D@nyu.edu> <4EC5329F.6060001@jhu.edu> Message-ID: On Nov 17, 2011, at Nov 17, 11:13 AM, Jonathan Rochkind wrote: > On 11/17/2011 8:58 AM, Scot Dalton wrote: >> Will Umlaut 3.0 still gather services for a given request into a collection based on the groups that are in play for that request? If so, will the logic for gathering services be customizable? > > I am not sure Umlaut _ever_ did this! Umlaut does not have any logic in it to determine what groups/institutions are in play for a given request. I know you were working on that. I got nervous about being able to do that in a way that is actually flexible enough for everyone, but without being a monster. I think the best way to do this, especially in a Rails 3.0 engine environment which makes it somewhat easier, is to allow local custom logic to be written however you want to do this. Collection#calculate_collection_data had the beginnings of this in Umlaut 2 and there were stubs/commented code for the other two pieces in the logic I laid out, but you're right that it was never fully developed. If this service gathering becomes customizable, then that meets our needs. Thanks, Scot -- Scot Dalton Phone: (212) 998-2674 Web Services Division of Libraries New York University From rochkind at jhu.edu Thu Nov 17 13:57:35 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 17 Nov 2011 13:57:35 -0500 Subject: [Umlaut-general] refactoring warnings In-Reply-To: References: <4EC400EB.6050407@jhu.edu> <02148C5F-5577-4686-B182-F9BD0D057A4D@nyu.edu> <4EC5329F.6060001@jhu.edu> Message-ID: <4EC5591F.8000609@jhu.edu> Cool. I wanna move it to the controller instead of inside Collection, I think that'll end up working out better, and make Collection easier to test and seperate concerns better. Collection just gets initialized with it's service list, whoever is initializing Collection calculates what the service list will be and tells Collection that. But thanks for drawing my attention to that method, I'll try to save what logic there makes sense and can be done cleanly when I move the logic to a new place. I _think_ this will work out well. if it needs tweaking, we'll tweak it! And I'm not averse to having things that make sense as possibly widely wanted features in Umlaut instead of local code, but the benefit of the Rails 3.0 gem approach should in allowing us to put the right _hooks_ in Umlaut code to let local apps do things custom, instead of needing to put every possible way of doing things anyone might ever want in Umlaut code. Things that we expect many people will often want, can/should still be built in of course. On 11/17/2011 1:52 PM, Scot Dalton wrote: > On Nov 17, 2011, at Nov 17, 11:13 AM, Jonathan Rochkind wrote: > >> On 11/17/2011 8:58 AM, Scot Dalton wrote: >>> Will Umlaut 3.0 still gather services for a given request into a collection based on the groups that are in play for that request? If so, will the logic for gathering services be customizable? >> I am not sure Umlaut _ever_ did this! Umlaut does not have any logic in it to determine what groups/institutions are in play for a given request. I know you were working on that. I got nervous about being able to do that in a way that is actually flexible enough for everyone, but without being a monster. I think the best way to do this, especially in a Rails 3.0 engine environment which makes it somewhat easier, is to allow local custom logic to be written however you want to do this. > Collection#calculate_collection_data had the beginnings of this in Umlaut 2 and there were stubs/commented code for the other two pieces in the logic I laid out, but you're right that it was never fully developed. If this service gathering becomes customizable, then that meets our needs. > > Thanks, > Scot > > > -- > Scot Dalton > Phone: (212) 998-2674 > Web Services > Division of Libraries > New York University > From std5 at nyu.edu Thu Nov 17 15:47:53 2011 From: std5 at nyu.edu (Scot Dalton) Date: Thu, 17 Nov 2011 15:47:53 -0500 Subject: [Umlaut-general] refactoring warnings In-Reply-To: <4EC5591F.8000609@jhu.edu> References: <4EC400EB.6050407@jhu.edu> <02148C5F-5577-4686-B182-F9BD0D057A4D@nyu.edu> <4EC5329F.6060001@jhu.edu> <4EC5591F.8000609@jhu.edu> Message-ID: On Nov 17, 2011, at Nov 17, 1:57 PM, Jonathan Rochkind wrote: > I _think_ this will work out well. if it needs tweaking, we'll tweak it! And I'm not averse to having things that make sense as possibly widely wanted features in Umlaut instead of local code, but the benefit of the Rails 3.0 gem approach should in allowing us to put the right _hooks_ in Umlaut code to let local apps do things custom, instead of needing to put every possible way of doing things anyone might ever want in Umlaut code. Things that we expect many people will often want, can/should still be built in of course. Sounds perfectly reasonable. Thanks! Scot -- Scot Dalton Phone: (212) 998-2674 Web Services Division of Libraries New York University From std5 at nyu.edu Mon Nov 21 16:12:29 2011 From: std5 at nyu.edu (Scot Dalton) Date: Mon, 21 Nov 2011 16:12:29 -0500 Subject: [Umlaut-general] Strange Search Result Using SFX4 Message-ID: <2649E300-91A0-4BB7-A701-46F44EF0B54F@nyu.edu> Hi all, We have a case here of Umlaut searching for an SFX title and getting unexpected results (it's present at JHU as well). If we do a contains search for "The American Journal of Pathology", we get taken directly to "American journal of forensic medicine & pathology" If we do either an exact search or begins with search for "The American Journal of Pathology", we get taken directly to "The American Journal of Pathology" I would expect the first search to take the user to a search result page. Thanks, Scot -- Scot Dalton Phone: (212) 998-2674 Web Services Division of Libraries New York University From rochkind at jhu.edu Mon Nov 21 16:53:04 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Mon, 21 Nov 2011 16:53:04 -0500 Subject: [Umlaut-general] Strange Search Result Using SFX4 In-Reply-To: <2649E300-91A0-4BB7-A701-46F44EF0B54F@nyu.edu> References: <2649E300-91A0-4BB7-A701-46F44EF0B54F@nyu.edu> Message-ID: <4ECAC840.7060103@jhu.edu> Weird. Umlaut's actually directly connecting to SFX MySQL db, using the tables that SFX builds for A-Z searching, and executing SQL directly against them, in order to do this kind of search. Apparently it's got a bug in it, or is otherwise not doing this the same way SFX itself is. Not sure if I'll have time to debug anytime soon, neck deep in trying to create Umlaut 3.0 at present. On 11/21/2011 4:12 PM, Scot Dalton wrote: > Hi all, > > We have a case here of Umlaut searching for an SFX title and getting unexpected results (it's present at JHU as well). > > If we do a contains search for "The American Journal of Pathology", we get taken directly to "American journal of forensic medicine& pathology" > If we do either an exact search or begins with search for "The American Journal of Pathology", we get taken directly to "The American Journal of Pathology" > > I would expect the first search to take the user to a search result page. > > Thanks, > Scot > > -- > Scot Dalton > Phone: (212) 998-2674 > Web Services > Division of Libraries > New York University > > _______________________________________________ > Umlaut-general mailing list > Umlaut-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/umlaut-general From std5 at nyu.edu Mon Nov 21 16:56:56 2011 From: std5 at nyu.edu (Scot Dalton) Date: Mon, 21 Nov 2011 16:56:56 -0500 Subject: [Umlaut-general] Strange Search Result Using SFX4 In-Reply-To: <4ECAC840.7060103@jhu.edu> References: <2649E300-91A0-4BB7-A701-46F44EF0B54F@nyu.edu> <4ECAC840.7060103@jhu.edu> Message-ID: It's not hugely important. I'll investigate further if I get a chance. Thanks, Scot On Nov 21, 2011, at Nov 21, 4:53 PM, Jonathan Rochkind wrote: > Weird. Umlaut's actually directly connecting to SFX MySQL db, using the tables that SFX builds for A-Z searching, and executing SQL directly against them, in order to do this kind of search. Apparently it's got a bug in it, or is otherwise not doing this the same way SFX itself is. Not sure if I'll have time to debug anytime soon, neck deep in trying to create Umlaut 3.0 at present. > > On 11/21/2011 4:12 PM, Scot Dalton wrote: >> Hi all, >> >> We have a case here of Umlaut searching for an SFX title and getting unexpected results (it's present at JHU as well). >> >> If we do a contains search for "The American Journal of Pathology", we get taken directly to "American journal of forensic medicine& pathology" >> If we do either an exact search or begins with search for "The American Journal of Pathology", we get taken directly to "The American Journal of Pathology" >> >> I would expect the first search to take the user to a search result page. >> >> Thanks, >> Scot >> >> -- >> Scot Dalton >> Phone: (212) 998-2674 >> Web Services >> Division of Libraries >> New York University >> >> _______________________________________________ >> Umlaut-general mailing list >> Umlaut-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/umlaut-general -- Scot Dalton Phone: (212) 998-2674 Web Services Division of Libraries New York University From rochkind at jhu.edu Mon Nov 28 16:11:56 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Mon, 28 Nov 2011 16:11:56 -0500 Subject: [Umlaut-general] hpricot, old news Message-ID: <4ED3F91C.6080507@jhu.edu> Looks like Hpricot conflicts with XmlBuilder in Rails 3.1. We use both. Doh. Doesn't look like anyone is maintaining Hpricot or planning on fixing this. Nor does it look like XmlBuilder is planning on fixing it. (Both try to monkey path a method with the same name but different semantics into String). I guess I'll go through all Umlaut services that use Hpricot and try to switch em to use Nokogiri. I'm not sure that Nokogiri is strictly api compatible with Hpricot. The aleph/primo services seem to use Hpricot; I'll try to switch them too, but won't be testing what I've changed, at least not right away. But this really just one of several things I've changed in those services I haven't been able to test; Scot, do you have servers that aren't firewalled and dont' require passwords at, that I could point primo services at to test em? From rochkind at jhu.edu Tue Nov 29 16:25:52 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Tue, 29 Nov 2011 16:25:52 -0500 Subject: [Umlaut-general] bx, anyone have it? Message-ID: <4ED54DE0.70204@jhu.edu> Anyone who has Bx, could you let me use your Bx to test the Umlaut Bx service against, so I can make sure it still works after I switch out hpricot for nokogiri?