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