after I read your message about granularity of authentication I have few
- how do you give permissions to public or private items in the same
- Do you use the dspace-admin account or there is another method
whithout the dspace-admin account and without changing the permissions
of the collection every time that a new item is inserted?
Thanks in advance
Leonie Hayes wrote:
> Hi Eric and others re Theses authentication
> We find DSpace really good for dealing with the minority of work that
> needs more complex restrictions.
> 90% or more of our items belong in the first category and we try to
> encourage this. There is always going to be other work that has complex
> authentication/access issues so we have put some examples in place see
> links below.
> The three levels of access to theses in ResearchSpace are:
> 1. No restriction. Thesis is freely available for download over the
> Internet. An example is at http://hdl.handle.net/2292/375
> 2. Medium restriction. Abstract and front matter (up to Chapter 1) is
> freely available for download, but the rest of the thesis is restricted
> to administrator-only access. An example is at
> 3. High restriction. The full text of the thesis is locked down for
> administrator-only access. The information available on ResearchSpace is
> the same access as provided in Voyager, the University of Auckland's
> online Library Catalogue.
> An example is at http://hdl.handle.net/2292/403
> Leonie Hayes
> Project Manager
> Institutional Repositories Aotearoa
> University of Auckland Library
> New Zealand
> -----Original Message-----
> From: dspace-tech-bounces@...
> [mailto:dspace-tech-bounces@...] On Behalf Of
> Sent: Saturday, 21 April 2007 7:10 a.m.
> To: dspace-tech@...
> Subject: DSpace-tech Digest, Vol 12, Issue 45
> Send DSpace-tech mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of DSpace-tech digest..."
> Today's Topics:
> 1. Re: DSpace a memory hog? (Brad Teale)
> 2. Re: Config Submission notes (Tim Donohue)
> 3. Re: browse index problem (Jeffrey Trimble)
> 4. Re: granularity of authentication for undergrad theses (Adam Brin)
> 5. recommendations for a high-performance installation
> (Deborah Kaplan)
> Message: 1
> Date: Fri, 20 Apr 2007 11:28:11 -0500
> From: Brad Teale <teale003@...>
> Subject: Re: [Dspace-tech] DSpace a memory hog?
> To: Cory Snavely <csnavely@...>
> Cc: dspace-tech@...
> Message-ID: <4628EA1B.1050009@...>
> Content-Type: text/plain; charset=ISO-8859-1
> Comments below:
> On 04/18/2007 01:54 PM, Cory Snavely wrote:
>> Well, as I said at first, it all depends on your definition of what a
>> memory hog is. Today's hog fits in tomorrow's pocket. We better all
>> already be used to that.
> Thank you for proving my point on memory bloat pervasiveness in the IT
> industry. This type of thinking allows vendors (whether open source or
> proprietary) to drive up the "base" systems requirements without greatly
> improving functionality because it is predestined.
>> Also, I don't think for a *minute* that the original developers of
>> DSpace made a casual choice about their development environment--in
>> fact, I think they made a responsible choice given the alternatives.
>> Let's give our colleagues credit that's due. Their choice permits
>> scaling and fits well for an open-source project. Putting the general
>> problem of memory bloat in their laps seems pretty angsty to me.
>> Lastly, dedicating a server to DSpace is a choice, not a necessity. We
>> as implementors have complete freedom to separate out the database and
>> storage tiers, and mechanisms exist for scaling Tomcat horizontally as
>> well. In the other direction, I suspect people are running DSpace on
>> VMware or xen virtual machines, too.
> I didn't say they made a casual choice about their development
> environment. I said the functional requirements of the application
> didn't justify the memory footprint required to run this application.
> Whether or not they made a choice that "fits well for an open-source
> project" depends on your definition of Open Source. However, I don't
> think that debate is relevant to this discussion.
> As far as scaling requirements, it depends on where you want
> scalability. As you pointed out, there is a natural ability with web
> applications to scale them vertically through hardware or Tomcat's, now
> native, horizontal approach. Since either approach needs hardware, the
> memory footprint of an application needs to be taken into account. The
> higher the "base" system requirements, the likelihood of someone having
> a scalable system is lowered due to total cost of ownership (TCO).
> While virtual machine technology can help lower some TCO issues, it
> brings in a whole new batch of problems which are out of scope for this
> The general problem of memory bloat rests in all developers laps (mine
> included). As an industry, we need to constantly weigh our use of
> memory against the functionality we are providing. The functionality
> provided by Dspace isn't rocket science, and shouldn't require memory
> footprints greater than most of systems that get people into space.
/ / Jesús Martín García
C E / S / C A Tècnic en Sistemes
/_/ Centre de Supercomputació de Catalunya
Gran Capità 2-4 (Edifici Nexus) 08034 Barcelona
T. 93 205 6464 F. 93 205 6979 jmartin@...