Il 15/11/2014 02.57, Mark Diggory ha scritto:
...
I'm not sure if https://jira.duraspace.org/browse/DS-1637 really meets
the design goal to split off the Handle service entirely from DSpace.
It still looks to be a plugin to the existing local handle server.
Yes the remote handle service plugin is a way to expose the internal
handle storage of DSpace to a central handle server. The single DSpace
is still responsible for handle mint and resolution. With this
functionality we are able to run a single handle server daemon in our
farm for all hosting DSpace installation.
Hope this help to clarify,
Andrea
Problems with the local DSpace handle service that really need fixing...
1.) cannot mint under multiple prefixes and opaque unique suffixes
with their own naming conventions.
2.) doesn't implement caching/bulk replication API, so if DSpace is
offline, so is resolution via hdl.handle.net <http://hdl.handle.net/>.
3.) DSpace conflates actual Handle with local identifier for
Item/Community/Collection
A HandleIdentifierProvider that remotely registers handles with an
organizational handle service would resolve both these issues. Looks
like MarkW already identified this as well...
https://jira.duraspace.org/browse/DS-2153
Regards,
Mark
On Fri, Nov 14, 2014 at 8:02 AM, Peter Dietz <pe...@longsight.com
<mailto:pe...@longsight.com>> wrote:
Hi All,
I've been reading up on the various configurations that you can
run DSpace and the handle service in, and I was wondering if
people would be willing to share their experiences with "non
traditional" set ups.
So, the out-of-the-box traditional setup, that I'm guessing 99% of
us use is to run DSpace, and configure the start-handle-server to
connect to DSpace using java (loads the dspace jars, gets access
to DSpace API org.dspace.handle.HandlePlugin, tries to resolve the
incoming request with that DSpace).
So, for an upcoming project, imagine that someone wants to be able
to take a collection OUT of DSpace, and put it into another
application on their campus. If they wanted their handles to
continue to resolve, the new application would need to speak
handle, but the handle service would need to know how to resolve
handles to multiple applications.
I know there have been some enhancements to DSpace over the years,
I was just wondering if anyone who had experience with them could
share what is possible, or if there is work that still needs to be
done in this area.
One of the new enhancements to DSpace is to allow the handle
service to be on an external server from DSpace:
https://jira.duraspace.org/browse/DS-1637
It adds some additional endpoints in XMLUI/JSPUI to respond in
text, which an external handle service could use to resolve. Then
the box that runs DSpace, can be properly firewalled, on a private
IP address, and not have world accessible ports coming in. (Your
external webserver, and external handle service would be public,
but know how to internally connect to DSpace).
So, some XMLUI endpoints, that external handle service could use
to resolve:
http://trydspace5.longsight.com/handleresolver/listprefixes
["123456789"]
http://trydspace5.longsight.com/handleresolver/listhandles/123456789
["123456789/1","123456789/2","123456789/3","123456789/79","123456789/77","123456789/6","123456789/7"]
http://trydspace5.longsight.com/handleresolver/resolve/123456789/79
["http://trydspace5.longsight.com/handle/123456789/79";]
As far as I understand it. DSpace provides a route to allow a
handle service to determine if DSpace contains that content. If
you moved a collection from DSpaceA to repositoryX, you would need
to have a handle service that knew how to lookup both DSpaceA and
repositoryX to see if one of them can resolve that handle?
And then another question along this same line. Say you have
multiple applications on campus, and wanted each to be capable of
minting handles, has anyone ever worked on a process to have each
application contact this central handle resolver to ensure that
the handle it wants to mint is available? I imagine this would be
some type of transaction, to ensure that competition among
consumer applications doesn't lead to a conflict. (Both apps ask
if handle is in use, both hear no, each mints, each posts back to
handle service that its has just minted it, and then, how to roll
back, or handle that state). Ivan mentioned to me, that they just
assign handle ranges to each application.
i.e. DSpaceA = 0-(1M-1), DSpaceB = 1M-(2M-1)
I suppose another route, would be to just use a UUID, and not
worry about colliding. And then, another thing that I think would
be possible, but I would need clarification is: handle prefixes
with dots. Such as 1234.1 or 1234.thesis or 1234.dspace1. Are you
allowed to claim an additional prefix with a dot, or do you have
to ($) register that with the handle authority?
Another thing I was just thinking, that instead of allocating
million record chunks to each application, what if you prefixed
your suffix, with the application that will be doing the minting?
i.e. 1234/thesis-678, 1234/thesis-679, or 1234/a-678, or
1234/dspace1-678
Another trick that I've just seen, not related to how handles will
resolve inside your institution, but it appears that the CNRI
handle authority now has an API to look at resolutions:
http://hdl.handle.net/api/handles/10827/16924
{"responseCode":1,"handle":"10827/16924","values":[{"index":100,"type":"URL","data":{"format":"string","value":"http://dc.statelibrary.sc.gov/handle/10827/16924"},"permissions":"1010","ttl":100,"timestamp":"1970-01-01T00:01:40Z"}]}
So yes, apologies if this was lots of questions, but I'm thinking
that since handles have been in use for so long, that people might
be needing additional tools to help keep these identifiers persistent.
________________
Peter Dietz
Longsight
www.longsight.com <http://www.longsight.com>
pe...@longsight.com <mailto:pe...@longsight.com>
p: 740-599-5005 x809 <tel:740-599-5005%20x809>
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push
notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
<mailto:DSpace-tech@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette:
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
--
@mire Inc.
*Mark Diggory*
/2888 Loker Avenue East, Suite 315, Carlsbad, CA. 92010/
/Esperantolaan 4, Heverlee 3001, Belgium/
http://www.atmire.com <http://www.atmire.com/>
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
--
Andrea Bollini
Soluzioni per la Ricerca Istituzionale
Cineca
Via dei Tizii, 6
00185 Roma, Italy
tel. +39 06 44 486 087 - mob. +39 348 82 77 525
http://www.cineca.it
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
