lib-ir Archive
Date: Thu Mar 31 09:17:29 2005
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: lib-ir: links to Scholars' Bank



I think this is something that we need to TALK about
in our meeting on the 11th. I want to be sure that
I understand the full implications before this kind of
change is made and I can't be sure by reading emails.
I need to be able to ask questions and get more
detailed explanations in a live setting.

Carol

At 12:50 PM 3/30/2005, you wrote:
>I have no real preference as to whether we push the port 80 address or the 
>SSL address on port 443.
>
>I can get rid of the /dspace portion of the URL all together if we want to 
>do so.  A url that included this portion would still work, but if you just 
>went to https://scholarsbank.uoregon.edu, all the links would stay within 
>that context (i.e. they wouldn't have the /dspace extension when 
>navigating around the repository).
>
>All this would require would be to:
>- Add the Asset dir that has our images to the jsp folder in the source 
>tree.
>- Add a step at deployment where you wipe the ROOT tomcat directory and 
>make a copy of the dspace.war file called ROOT.war.  All the 
>configurations would be the same.
>- Kill the redirect that points from vanilla scholarsbank URL to the URL 
>with the /dspace directory.
>
>I've tested this on irtest and it works fine (apologies for the 8443 in 
>the url.  I've got mod_jk2 on irtest, but don't have redirects behaving 
>exactly as on scholarsbank, so the port is necessary to demonstrate how 
>this works.)
>
>https://irtest.uoregon.edu:8443/
>Notice that any link you follow stays within this ROOT context.  Also, 
>note that the https://irtest.uoregon.edu:8443/dspace URL also still works, 
>but all of its links stay within the /dspace context.  Tomcat sees these 
>as two separate instances of dspace, although they are deployments of the 
>same thing.
>
>The only thing I haven't been able to test on irtest is how to make the 
>handle server know which context to use.  It should be derived from 
>dspace's config file, but I can't be certain.
>
>I do have one potential caveat setting up Scholars' Bank in this way, or 
>even advertising the address without the /dspace portion at the end of the 
>url and keeping the redirect in place:  I can envision a day when DSpace 
>is not the only application or page set housed on the Scholars' Bank 
>server.  One of the nice things about having mod_jk2 in place is that we 
>could easily move IRG pages (at least those that are for external 
>consumption) over to Scholars' Bank so that our users are consistently 
>visiting the same host.
>
>Additionally, I could see us wanting to run software architectures other 
>than DSpace on this server.  If we find that EPrints or Fedora have 
>functionality that we want, is it set in stone that our IR only uses one 
>system architecture?  There's even been some discussion of DSpace forking 
>into more than one platform, would we want to limit ourselves in this 
>way?  I could picture a future where we have a variety of URLs, such as:
>
>https://scholarsbank.uoregon.edu/dspace
>https://scholarsbank.uoregon.edu/eprints
>https://scholarsbank.uoregon.edu/simile (if this ever really gets off the 
>ground)
>http://scholarsbank.uoregon.edu/about
>
>The nice thing about our current set up is that some of these may be 
>running under Tomcat, others may just run under apache.  Some may use pure 
>http, others the secure socket layer.  Perhaps, in this scenario, the root 
>of Scholars Bank is actually a homegrown SRU / SRW interface that searches 
>across all this stuff.  Maybe there's a cross platform OAI interface 
>thrown in there somewhere, too.
>
>Admittedly, it's cleaner to have a the url not reference dspace 
>directly.  And it can be done.  But it may limit us in the future, or 
>force us to rethink the decision.  I guess we wouldn't really have to 
>re-advertise much.  If we moved scholarsbank to the root context now, 
>we'll still have the dspace context running and we can always kill the 
>DSpace on ROOT setup and put something more inclusive there.  Scholars' 
>Bank would still be Scholar's Bank, only it's appearance will have changed.
>
>This is probably something we should try to talk about at a future 
>meeting, although maybe not the upcoming one, as that agenda looks pretty full.
>
>-Corey
>
>Corey A Harper
>Metadata Librarian - CMET Team Leader
>Metadata and Digital Library Services
>University of Oregon
>541/346.1854
><mailto:charper@darkwing.uoregon.edu>charper@darkwing.uoregon. 
><mailto:charper@darkwing.uoregon.edu>edu
>
>At 10:51 AM 3/30/2005, you wrote:
>>Sorry.  I was unclear.  Yes, the actual handouts are definitely correct.
>>But if you look in your Address: line in your browser you see /dspace, which
>>may not be desirable or necessary (or maybe it is...).  mod_jk2 succesfully
>>hid the 8443 port, which was great but just whetted my appetite for even
>>greater neatness.
>>
>>Are we advertising http://scholarsbank.uoregon.edu or
>>https://scholarsbank.uoregon.edu ?
>>
>>-----Original Message-----
>>From: owner-lib-ir@lists.uoregon.edu [ mailto:owner-lib-ir@lists.uoregon.edu]
>>On Behalf Of Carol Hixson
>>Sent: Wednesday, March 30, 2005 8:59 AM
>>To: Institutional Repository Group
>>Subject: RE: lib-ir: links to Scholars' Bank
>>
>>
>>
>>The URL that we hand out is the correct one. At least,
>>when I advertise it or do handouts it is. One of the things
>>I'm working on now are a series of handouts for other
>>people to use when talking about the archive. I was just talking with
>>Barbara about that this morning.
>>
>>At 08:49 AM 3/30/2005, you wrote:
>> >At some point we should probably put some effort into hiding the
>> >internal structure and making sure that the URLs we hand out for the
>> >home page are just https://scholarsbank.uoregon.edu/
>>
>>As for the site that has the wrong address, we can contact
>>them and ask them to change their link.
>>
>>Carol