From rochkind at jhu.edu Tue Sep 6 16:09:55 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Tue, 06 Sep 2011 16:09:55 -0400 Subject: [Umlaut-general] updated Amazon adapter in svn Message-ID: <4E667E13.9040304@jhu.edu> I've committed updates to the Amazon adapter, it now screen-scrapes the latest Amazon interface instead of an old Amazon interface at a different URL. The Amazon adapter needs to screen-scrape to determine "look inside" and "search inside" availability, to link to. To do this, it predicts the URL for the "look inside" page, and then screen-scrapes whats' there. The previous version was screen-scraping an old version of the "look inside" page, that was somehow still available at an alternate URL from Amazon, but was behaving increasingly erratically. Fixed it to screen scrape the latest version of this interface instead. It's a bit tricky to reverse engineer the HTML to figure out what to look for in HTML to determine availabiltiy of "look inside" and "search inside", but I think I figured it out properly, tested it on a bunch of sample data, appears to be working. If you update the lib/service_adapters/amazon.rb file from svn, you'll have the new code. From rochkind at jhu.edu Wed Sep 7 15:31:57 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Wed, 07 Sep 2011 15:31:57 -0400 Subject: [Umlaut-general] new Google Book Search adapter Message-ID: <4E67C6AD.2010809@jhu.edu> The previous Umlaut Google Books adapter was using a version of the Google Books API that is going away December 1st. I updated it to use the new Google API. The old adapter, using the old API, is still available as OldGoogleBookSearch, if you svn up but want to continue using the old version of the API (before Dec 1). The new version should do pretty much the same thing as the old version. I just deployed it in production, and am seeing some problems with Google Books giving me a 503 errors to my requests, and reporting "Cannot determine user location." -- not sure why as I'm still sending the user location same as I always did in the way Google wants. Working on figuring that out, so you may want to avoid using the new one until I do. The other difference with the new one is an API key is strongly suggested -- the old Google API had no rate limits, without an API key. the new API is advertised to require an API key -- it seems to work without one, but probably with extreme rate limits. You'll also want to submit the form asking for increased rate quota for your API key, the default 1000/day probably won't be enough -- I asked for 50k, and got it within 24 hours with no questions asked. # = Google API Key # # Setting an api key in :api_key STRONGLY recommended, or you'll # probably get rate limited (not clear what the limit is with no api # key supplied). You may have to ask for higher rate limit for your api # key than the default 1000/day, which you can do through the google # api console: # https://code.google.com/apis/console # # I requested 50k with this message, and was quickly approved with no questions # "Services for academic library (Johns Hopkins Libraries) web applications to match Google Books availability to items presented by our catalog, OpenURL link resolver, and other software. " # # Recommend setting your 'per user limit' to something crazy high, as well # as requesting more quota. From std5 at nyu.edu Wed Sep 7 16:33:31 2011 From: std5 at nyu.edu (Scot Dalton) Date: Wed, 7 Sep 2011 16:33:31 -0400 Subject: [Umlaut-general] Institutions vs. Groups Message-ID: <1B1FDEFB-9046-4056-9FE3-E9A1A127A626@nyu.edu> Hi all, I'm well on my way with building out Umlaut to handle different groups of users. One design decision that I'd like some input on is how to persist data about layouts, search methods, resolve serivce, IP ranges etc. I'm considering two approaches, detailed below, that I'd like some feedback on. 1.) Institutions Institutions would have information about IP ranges, layouts, search methods, resolve services, etc. Basically any information regarding a set of configurations for display, searching and link resolution. Since there is no longer an institutions table, the table linking users to institutions doesn't work and would be replaced with a serialized column on the users table that associates users with institutions, designating one as the primary institution (to determine layouts and search methods). Pros: very straightforward to implement Cons: not very extensible; stores both display information and core services/functionality in the same place 2.) Groups Groups have many and belong to users. Groups store information about layouts and IP ranges for display purposes. Users would have a primary group to determine the layouts used. A group would also have an institution associated with it. Institutions would contain information about search methods and resolution services. Groups would tie users to institutions and allow user to get multiple services. Pros: separate out display data from services and search functionality; extensible Cons: more work; probably over engineered Let me know what you think of these two options. I'll probably start working on it tomorrow. I'm really not sold one way or the other, so any advice would be appreciated. Thanks, Scot -- Scot Dalton Phone: (212) 998-2674 Web Services Division of Libraries New York University From rochkind at jhu.edu Wed Sep 7 16:56:41 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Wed, 07 Sep 2011 16:56:41 -0400 Subject: [Umlaut-general] Institutions vs. Groups In-Reply-To: <1B1FDEFB-9046-4056-9FE3-E9A1A127A626@nyu.edu> References: <1B1FDEFB-9046-4056-9FE3-E9A1A127A626@nyu.edu> Message-ID: <4E67DA89.8020401@jhu.edu> I think you should keep it as simple as you think you can to do what you want. It looks to me like your #2 includes the Institutions from #1, _plus_ something more. So I'd go with #1, which is simpler. Also, you mention "since there is no longer an institutions table" -- I can't remember if I took that out or it got taken out before even Umlaut 2, but either way, if you think your feature can get done cleaner/neater/more-maintainable/more-performant with an Institutions table, then you can add one! What's a "resolve service" in your list of things that may vary by Institution? Also, please document everything well once yu've done it -- I dont mean in code comments, I mean some high level documentation about how this feature is intended to be used, and how to use it. Also, I'm _still_ going to try to do a major refactor of Umlaut to Rails3 and ruby 1.9.x in the next few months, hopefully this additional functionality will transfer well, but I'll need to understand it to try and migrate it, thus the request for docs! (Alternately, leave it un-migrated and make you migrate it. :) ). Also, heads up, at some point in the near future, at some point before I start on my refactor, I want to move Umlaut from rubyforge/svn to github/git. Scot, do you have any feelings pro or con about git or github? Used git before? As far as I'm concerned, Umlaut can move to github at any time, although I won't do it without coordinating with you, and wont' do it myself until I get to it. But it could move sooner if someone wanted to move it and update documentation (including installation documentation etc, since at the moment Umlaut's still installed with a source checkout). On 9/7/2011 4:33 PM, Scot Dalton wrote: > Hi all, > I'm well on my way with building out Umlaut to handle different groups of users. One design decision that I'd like some input on is how to persist data about layouts, search methods, resolve serivce, IP ranges etc. I'm considering two approaches, detailed below, that I'd like some feedback on. > > 1.) Institutions > Institutions would have information about IP ranges, layouts, search methods, resolve services, etc. Basically any information regarding a set of configurations for display, searching and link resolution. > Since there is no longer an institutions table, the table linking users to institutions doesn't work and would be replaced with a serialized column on the users table that associates users with institutions, designating one as the primary institution (to determine layouts and search methods). > > Pros: very straightforward to implement > Cons: not very extensible; stores both display information and core services/functionality in the same place > > 2.) Groups > Groups have many and belong to users. Groups store information about layouts and IP ranges for display purposes. Users would have a primary group to determine the layouts used. A group would also have an institution associated with it. Institutions would contain information about search methods and resolution services. Groups would tie users to institutions and allow user to get multiple services. > > Pros: separate out display data from services and search functionality; extensible > Cons: more work; probably over engineered > > Let me know what you think of these two options. I'll probably start working on it tomorrow. I'm really not sold one way or the other, so any advice would be appreciated. > > 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 rochkind at jhu.edu Wed Sep 7 18:03:25 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Wed, 07 Sep 2011 18:03:25 -0400 Subject: [Umlaut-general] Institutions vs. Groups In-Reply-To: <4E67DA89.8020401@jhu.edu> References: <1B1FDEFB-9046-4056-9FE3-E9A1A127A626@nyu.edu> <4E67DA89.8020401@jhu.edu> Message-ID: <4E67EA2D.6060707@jhu.edu> Oh, I'd also be really interested in understanding your use case that you are actually writing this for: I don't think you've actually told us yet, and I've got some guesses, but don't really know. On 9/7/2011 4:56 PM, Jonathan Rochkind wrote: > I think you should keep it as simple as you think you can to do what > you want. > > It looks to me like your #2 includes the Institutions from #1, _plus_ > something more. So I'd go with #1, which is simpler. > > Also, you mention "since there is no longer an institutions table" -- > I can't remember if I took that out or it got taken out before even > Umlaut 2, but either way, if you think your feature can get done > cleaner/neater/more-maintainable/more-performant with an Institutions > table, then you can add one! > > What's a "resolve service" in your list of things that may vary by > Institution? > > Also, please document everything well once yu've done it -- I dont > mean in code comments, I mean some high level documentation about how > this feature is intended to be used, and how to use it. > > Also, I'm _still_ going to try to do a major refactor of Umlaut to > Rails3 and ruby 1.9.x in the next few months, hopefully this > additional functionality will transfer well, but I'll need to > understand it to try and migrate it, thus the request for docs! > (Alternately, leave it un-migrated and make you migrate it. :) ). > > Also, heads up, at some point in the near future, at some point before > I start on my refactor, I want to move Umlaut from rubyforge/svn to > github/git. Scot, do you have any feelings pro or con about git or > github? Used git before? As far as I'm concerned, Umlaut can move to > github at any time, although I won't do it without coordinating with > you, and wont' do it myself until I get to it. But it could move > sooner if someone wanted to move it and update documentation > (including installation documentation etc, since at the moment > Umlaut's still installed with a source checkout). > > > On 9/7/2011 4:33 PM, Scot Dalton wrote: >> Hi all, >> I'm well on my way with building out Umlaut to handle different >> groups of users. One design decision that I'd like some input on is >> how to persist data about layouts, search methods, resolve serivce, >> IP ranges etc. I'm considering two approaches, detailed below, that >> I'd like some feedback on. >> >> 1.) Institutions >> Institutions would have information about IP ranges, layouts, search >> methods, resolve services, etc. Basically any information regarding >> a set of configurations for display, searching and link resolution. >> Since there is no longer an institutions table, the table linking >> users to institutions doesn't work and would be replaced with a >> serialized column on the users table that associates users with >> institutions, designating one as the primary institution (to >> determine layouts and search methods). >> >> Pros: very straightforward to implement >> Cons: not very extensible; stores both display information and core >> services/functionality in the same place >> >> 2.) Groups >> Groups have many and belong to users. Groups store information about >> layouts and IP ranges for display purposes. Users would have a >> primary group to determine the layouts used. A group would also have >> an institution associated with it. Institutions would contain >> information about search methods and resolution services. Groups >> would tie users to institutions and allow user to get multiple services. >> >> Pros: separate out display data from services and search >> functionality; extensible >> Cons: more work; probably over engineered >> >> Let me know what you think of these two options. I'll probably start >> working on it tomorrow. I'm really not sold one way or the other, so >> any advice would be appreciated. >> >> 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 > _______________________________________________ > Umlaut-general mailing list > Umlaut-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/umlaut-general From std5 at nyu.edu Thu Sep 8 09:51:20 2011 From: std5 at nyu.edu (Scot Dalton) Date: Thu, 8 Sep 2011 09:51:20 -0400 Subject: [Umlaut-general] Institutions vs. Groups In-Reply-To: <4E67DA89.8020401@jhu.edu> References: <1B1FDEFB-9046-4056-9FE3-E9A1A127A626@nyu.edu> <4E67DA89.8020401@jhu.edu> Message-ID: On Sep 7, 2011, at Sep 7, 4:56 PM, Jonathan Rochkind wrote: > I think you should keep it as simple as you think you can to do what you want. > > It looks to me like your #2 includes the Institutions from #1, _plus_ something more. So I'd go with #1, which is simpler. Sounds good. > > Also, you mention "since there is no longer an institutions table" -- I can't remember if I took that out or it got taken out before even Umlaut 2, but either way, if you think your feature can get done cleaner/neater/more-maintainable/more-performant with an Institutions table, then you can add one! Don't think we need to add back the institutions table. I'll try to make the code as modular as possible, so if we need to switch it out in the future, it won't be too painful. > > What's a "resolve service" in your list of things that may vary by Institution? Just a service. Umlaut currently has a stub for this feature and has two institutions already defined, global and local. I'm fleshing this out a bit and hope to implement the "original intent" for institutions that Ross described in an earlier message, namely that institutions can have different services and we can have different combinations of institutions (and hence services) based on IP/user/URL. > > Also, please document everything well once yu've done it -- I dont mean in code comments, I mean some high level documentation about how this feature is intended to be used, and how to use it. Will do. > > Also, I'm _still_ going to try to do a major refactor of Umlaut to Rails3 and ruby 1.9.x in the next few months, hopefully this additional functionality will transfer well, but I'll need to understand it to try and migrate it, thus the request for docs! (Alternately, leave it un-migrated and make you migrate it. :) ). Either way works for me. > > Also, heads up, at some point in the near future, at some point before I start on my refactor, I want to move Umlaut from rubyforge/svn to github/git. Scot, do you have any feelings pro or con about git or github? Used git before? As far as I'm concerned, Umlaut can move to github at any time, although I won't do it without coordinating with you, and wont' do it myself until I get to it. But it could move sooner if someone wanted to move it and update documentation (including installation documentation etc, since at the moment Umlaut's still installed with a source checkout). Don't have much experience with git, but have been meaning to get into it, so this is a great opportunity to do so. I'm planning to start with Pro Git. [1] Any other recommendations on useful resources? Thanks, Scot [1] http://progit.org/book/ > > > On 9/7/2011 4:33 PM, Scot Dalton wrote: >> Hi all, >> I'm well on my way with building out Umlaut to handle different groups of users. One design decision that I'd like some input on is how to persist data about layouts, search methods, resolve serivce, IP ranges etc. I'm considering two approaches, detailed below, that I'd like some feedback on. >> >> 1.) Institutions >> Institutions would have information about IP ranges, layouts, search methods, resolve services, etc. Basically any information regarding a set of configurations for display, searching and link resolution. >> Since there is no longer an institutions table, the table linking users to institutions doesn't work and would be replaced with a serialized column on the users table that associates users with institutions, designating one as the primary institution (to determine layouts and search methods). >> >> Pros: very straightforward to implement >> Cons: not very extensible; stores both display information and core services/functionality in the same place >> >> 2.) Groups >> Groups have many and belong to users. Groups store information about layouts and IP ranges for display purposes. Users would have a primary group to determine the layouts used. A group would also have an institution associated with it. Institutions would contain information about search methods and resolution services. Groups would tie users to institutions and allow user to get multiple services. >> >> Pros: separate out display data from services and search functionality; extensible >> Cons: more work; probably over engineered >> >> Let me know what you think of these two options. I'll probably start working on it tomorrow. I'm really not sold one way or the other, so any advice would be appreciated. >> >> 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 std5 at nyu.edu Thu Sep 8 10:41:01 2011 From: std5 at nyu.edu (Scot Dalton) Date: Thu, 8 Sep 2011 10:41:01 -0400 Subject: [Umlaut-general] Institutions vs. Groups In-Reply-To: <4E67EA2D.6060707@jhu.edu> References: <1B1FDEFB-9046-4056-9FE3-E9A1A127A626@nyu.edu> <4E67DA89.8020401@jhu.edu> <4E67EA2D.6060707@jhu.edu> Message-ID: <4E275D90-C09E-4E36-A9D1-063D2DFC6490@nyu.edu> Right, use case. The basis for this is that we're part of a consortium of libraries with Cooper Union and The New School that have their own SFX instances and we're the main library tech shop for the NYU global network university, with portal campuses (degree granting entities) in several locations around the world. The consortium members aren't licensed to access our electronic resources remotely, but have access to our physical location and can access our resources from here. The consortium members have there own web presence, look & feel, and staff. The portal campuses currently share our SFX instance (theoretically this could change), and have there own web presence, look & feel, and staff. Additionally, in the near future, we hope to bring on board other division of NYU NY that have there own SFX instances, web presences, look & feel, and staff. Complicating this a bit is that some users can be associated with multiple consortium members and/or multiple portal campuses. We have some business logic that will determine the hierarchy of these affiliations. We're planning on hosting Umlaut for some consortium members and the portal campuses and would like to maintain one code base/configuration base for all the different groups. Use cases examples: 1. Consortium library user (logged in) at NYU NY location: Should by default get the NYU layout, NYU AZ search, and NYU & consortium library SFX resources (since they have access to both). Should also be able to access consortium library layout via URL. 2. Anonymous user at consortium library: Should by default get the consortium library layout, consortium library AZ search, and consortium library SFX resources. Should also be able to access any other library layout via URL. 3. Portal campus library user (logged in) at NYU NY location: Should by default get the NYU NY layout, NYU AZ search, and NYU SFX resources. Should also be able to access portal campus library layout via URL. 4. Anonymous user at portal campus: Should by default get the portal campus layout, NYU AZ search, and NYU SFX resources. Should also be able to access any other library layout via URL. It's straightforward to associate a layout and AZ search (including SFX db info) with an institution. It's also straightforward to associate and institution with an IP address and for determining layouts/AZ search. Based on the feedback below, I'll associate user and institutions at the user level and the business logic mentioned above will determine which is the user's primary institution. Switching the AZ search method per session is a little tricky, but ruby's meta programming aspects make it a easier to manage. So the "primary institution" will determine layout and AZ search and the hierarchy will be URL, IP, user, default. Services will display based on the primary institution, institutions affiliated by IP, and user institutions. The final little piece that I can think of, is that SFX urls may need an institution. It's easy to add an institution to a SFX url, but the tricky part will be determining which institutions are in play for a particular session and if SFX controls the URL for the session. I'll investigate how this would work. Of course, if no institution is specified, it would just check all SFX urls. Let me know if you have any questions or concerns. Thanks, Scot On Sep 7, 2011, at Sep 7, 6:03 PM, Jonathan Rochkind wrote: > Oh, I'd also be really interested in understanding your use case that you are actually writing this for: I don't think you've actually told us yet, and I've got some guesses, but don't really know. > > On 9/7/2011 4:56 PM, Jonathan Rochkind wrote: >> I think you should keep it as simple as you think you can to do what you want. >> >> It looks to me like your #2 includes the Institutions from #1, _plus_ something more. So I'd go with #1, which is simpler. >> >> Also, you mention "since there is no longer an institutions table" -- I can't remember if I took that out or it got taken out before even Umlaut 2, but either way, if you think your feature can get done cleaner/neater/more-maintainable/more-performant with an Institutions table, then you can add one! >> >> What's a "resolve service" in your list of things that may vary by Institution? >> >> Also, please document everything well once yu've done it -- I dont mean in code comments, I mean some high level documentation about how this feature is intended to be used, and how to use it. >> >> Also, I'm _still_ going to try to do a major refactor of Umlaut to Rails3 and ruby 1.9.x in the next few months, hopefully this additional functionality will transfer well, but I'll need to understand it to try and migrate it, thus the request for docs! (Alternately, leave it un-migrated and make you migrate it. :) ). >> >> Also, heads up, at some point in the near future, at some point before I start on my refactor, I want to move Umlaut from rubyforge/svn to github/git. Scot, do you have any feelings pro or con about git or github? Used git before? As far as I'm concerned, Umlaut can move to github at any time, although I won't do it without coordinating with you, and wont' do it myself until I get to it. But it could move sooner if someone wanted to move it and update documentation (including installation documentation etc, since at the moment Umlaut's still installed with a source checkout). >> >> >> On 9/7/2011 4:33 PM, Scot Dalton wrote: >>> Hi all, >>> I'm well on my way with building out Umlaut to handle different groups of users. One design decision that I'd like some input on is how to persist data about layouts, search methods, resolve serivce, IP ranges etc. I'm considering two approaches, detailed below, that I'd like some feedback on. >>> >>> 1.) Institutions >>> Institutions would have information about IP ranges, layouts, search methods, resolve services, etc. Basically any information regarding a set of configurations for display, searching and link resolution. >>> Since there is no longer an institutions table, the table linking users to institutions doesn't work and would be replaced with a serialized column on the users table that associates users with institutions, designating one as the primary institution (to determine layouts and search methods). >>> >>> Pros: very straightforward to implement >>> Cons: not very extensible; stores both display information and core services/functionality in the same place >>> >>> 2.) Groups >>> Groups have many and belong to users. Groups store information about layouts and IP ranges for display purposes. Users would have a primary group to determine the layouts used. A group would also have an institution associated with it. Institutions would contain information about search methods and resolution services. Groups would tie users to institutions and allow user to get multiple services. >>> >>> Pros: separate out display data from services and search functionality; extensible >>> Cons: more work; probably over engineered >>> >>> Let me know what you think of these two options. I'll probably start working on it tomorrow. I'm really not sold one way or the other, so any advice would be appreciated. >>> >>> 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 >> _______________________________________________ >> Umlaut-general mailing list >> Umlaut-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/umlaut-general > _______________________________________________ > 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 Thu Sep 8 12:00:21 2011 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 08 Sep 2011 12:00:21 -0400 Subject: [Umlaut-general] Institutions vs. Groups In-Reply-To: <4E275D90-C09E-4E36-A9D1-063D2DFC6490@nyu.edu> References: <1B1FDEFB-9046-4056-9FE3-E9A1A127A626@nyu.edu> <4E67DA89.8020401@jhu.edu> <4E67EA2D.6060707@jhu.edu> <4E275D90-C09E-4E36-A9D1-063D2DFC6490@nyu.edu> Message-ID: <4E68E695.7070404@jhu.edu> Thanks, helpful, makes sense. So Institution may sometimes be determined by having a logged in user, and other times by IP address? Cool. Yeah, with adding institution to SFX, one trick is with SFX request caching. If you request the same URL from Umlaut a second (or subsequent) time (in same session!), Umlaut will not start a new request for you, but just hook you up with the same "Request" object again. This is important both for general performance, and to make sure refreshes to get background services hook up with the same request, don't start off a new one. But I don't think the whole URL is used for matching cache, certain parameters are considered significant certain ones not. I forget exactly where the code is and how it decides, it may be confusing. So anyway, if institution is in the URL, you have to make sure that it _is_ deemed significant for request caching purposes -- requesting the otherwise same url with a different institution, you definitely want to launch a new Umlaut request, _not_ hook up with the previous request with a different institution or no institution. As far as "but the tricky part will be determining which institutions are in play for a particular session and if SFX controls the URL for the session. " I'm not sure what you mean by "if SFX controls the URL for the session". But in general, I guess you're talking about using both IP lookup and user account, and possibly Umlaut URL, to determine Institution in play? I'd actually avoid using a Rails session at all for this. Calculate it on for the individual request, perhaps add new attributes to the Umlaut Request model to save it for a request (recall as above that an Umlaut Request can be re-used accross HTTP requests) -- but don't try to save anything in the Rails session, will make things much less confusing. (Of course the current logged in user will be saved in Rails session, but that's it). On 9/8/2011 10:41 AM, Scot Dalton wrote: > Right, use case. The basis for this is that we're part of a consortium of libraries with Cooper Union and The New School that have their own SFX instances and we're the main library tech shop for the NYU global network university, with portal campuses (degree granting entities) in several locations around the world. The consortium members aren't licensed to access our electronic resources remotely, but have access to our physical location and can access our resources from here. The consortium members have there own web presence, look& feel, and staff. The portal campuses currently share our SFX instance (theoretically this could change), and have there own web presence, look& feel, and staff. Additionally, in the near future, we hope to bring on board other division of NYU NY that have there own SFX instances, web presences, look& feel, and staff. Complicating this a bit is that some users can be associated with multiple consortium members and/or multiple portal camp > uses. We have some business logic that will determine the hierarchy of these affiliations. > > We're planning on hosting Umlaut for some consortium members and the portal campuses and would like to maintain one code base/configuration base for all the different groups. > > Use cases examples: > 1. Consortium library user (logged in) at NYU NY location: > Should by default get the NYU layout, NYU AZ search, and NYU& consortium library SFX resources (since they have access to both). Should also be able to access consortium library layout via URL. > > 2. Anonymous user at consortium library: > Should by default get the consortium library layout, consortium library AZ search, and consortium library SFX resources. Should also be able to access any other library layout via URL. > > 3. Portal campus library user (logged in) at NYU NY location: > Should by default get the NYU NY layout, NYU AZ search, and NYU SFX resources. Should also be able to access portal campus library layout via URL. > > 4. Anonymous user at portal campus: > Should by default get the portal campus layout, NYU AZ search, and NYU SFX resources. Should also be able to access any other library layout via URL. > > It's straightforward to associate a layout and AZ search (including SFX db info) with an institution. It's also straightforward to associate and institution with an IP address and for determining layouts/AZ search. Based on the feedback below, I'll associate user and institutions at the user level and the business logic mentioned above will determine which is the user's primary institution. Switching the AZ search method per session is a little tricky, but ruby's meta programming aspects make it a easier to manage. > > So the "primary institution" will determine layout and AZ search and the hierarchy will be URL, IP, user, default. Services will display based on the primary institution, institutions affiliated by IP, and user institutions. > > The final little piece that I can think of, is that SFX urls may need an institution. It's easy to add an institution to a SFX url, but the tricky part will be determining which institutions are in play for a particular session and if SFX controls the URL for the session. I'll investigate how this would work. Of course, if no institution is specified, it would just check all SFX urls. > > Let me know if you have any questions or concerns. > > Thanks, > Scot > > > On Sep 7, 2011, at Sep 7, 6:03 PM, Jonathan Rochkind wrote: > >> Oh, I'd also be really interested in understanding your use case that you are actually writing this for: I don't think you've actually told us yet, and I've got some guesses, but don't really know. >> >> On 9/7/2011 4:56 PM, Jonathan Rochkind wrote: >>> I think you should keep it as simple as you think you can to do what you want. >>> >>> It looks to me like your #2 includes the Institutions from #1, _plus_ something more. So I'd go with #1, which is simpler. >>> >>> Also, you mention "since there is no longer an institutions table" -- I can't remember if I took that out or it got taken out before even Umlaut 2, but either way, if you think your feature can get done cleaner/neater/more-maintainable/more-performant with an Institutions table, then you can add one! >>> >>> What's a "resolve service" in your list of things that may vary by Institution? >>> >>> Also, please document everything well once yu've done it -- I dont mean in code comments, I mean some high level documentation about how this feature is intended to be used, and how to use it. >>> >>> Also, I'm _still_ going to try to do a major refactor of Umlaut to Rails3 and ruby 1.9.x in the next few months, hopefully this additional functionality will transfer well, but I'll need to understand it to try and migrate it, thus the request for docs! (Alternately, leave it un-migrated and make you migrate it. :) ). >>> >>> Also, heads up, at some point in the near future, at some point before I start on my refactor, I want to move Umlaut from rubyforge/svn to github/git. Scot, do you have any feelings pro or con about git or github? Used git before? As far as I'm concerned, Umlaut can move to github at any time, although I won't do it without coordinating with you, and wont' do it myself until I get to it. But it could move sooner if someone wanted to move it and update documentation (including installation documentation etc, since at the moment Umlaut's still installed with a source checkout). >>> >>> >>> On 9/7/2011 4:33 PM, Scot Dalton wrote: >>>> Hi all, >>>> I'm well on my way with building out Umlaut to handle different groups of users. One design decision that I'd like some input on is how to persist data about layouts, search methods, resolve serivce, IP ranges etc. I'm considering two approaches, detailed below, that I'd like some feedback on. >>>> >>>> 1.) Institutions >>>> Institutions would have information about IP ranges, layouts, search methods, resolve services, etc. Basically any information regarding a set of configurations for display, searching and link resolution. >>>> Since there is no longer an institutions table, the table linking users to institutions doesn't work and would be replaced with a serialized column on the users table that associates users with institutions, designating one as the primary institution (to determine layouts and search methods). >>>> >>>> Pros: very straightforward to implement >>>> Cons: not very extensible; stores both display information and core services/functionality in the same place >>>> >>>> 2.) Groups >>>> Groups have many and belong to users. Groups store information about layouts and IP ranges for display purposes. Users would have a primary group to determine the layouts used. A group would also have an institution associated with it. Institutions would contain information about search methods and resolution services. Groups would tie users to institutions and allow user to get multiple services. >>>> >>>> Pros: separate out display data from services and search functionality; extensible >>>> Cons: more work; probably over engineered >>>> >>>> Let me know what you think of these two options. I'll probably start working on it tomorrow. I'm really not sold one way or the other, so any advice would be appreciated. >>>> >>>> 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 >>> _______________________________________________ >>> Umlaut-general mailing list >>> Umlaut-general at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/umlaut-general >> _______________________________________________ >> 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 > > _______________________________________________ > Umlaut-general mailing list > Umlaut-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/umlaut-general