Lots of folks are better positioned than I to describe excellence in document repository software from the end-user or content-administrator or organizational-administrator POV, so I'll confine my comments to the operational and information-architecture POV.
o Leverages the organization's existing authentication and identity systems. DSpace has been getting better at the former, still shows room for improvement in the latter. (Example: when registering a user authenticated through LDAP, there's no need to store locator info. such as a phone number or email address, because we can just fetch those from the directory when asked, and if we *do* store them then the data become stale over time.) o Instrumented for monitoring and maintenance. This goes beyond statistics. Example: I want to build an application-level backup system under DSpace so that we can fan out several dead-storage copies of new acquisitions *once* rather than backing up terabytes of static files every week forever. To do that, my gadget needs to know when a new item comes in and how to identify it. o Configurable without rebuilding. I think the current setup process knows too much about deployment issues. DSpace is atypically good in this respect among the Java app.s I've seen, but I'd like to see even better decoupling between build time and runtime. (I haven't yet spent enough time with 1.5 to say how much the situation has improved there.) o Routine operational procedures should be completely automatable. Any operation which requires a sysadmin. to sit at a console and click buttons is a manual process. There should be no manual processes required for any repetitive task. (This isn't speaking about content ingestion, which is a creative activity and *should* be hands-on.) DSpace is good here -- I just want to keep it that way. o User functions exposed programmatically. The repository should be usable by machines, not just humans. Someone is going to come up with a use for our pool of documents which is quite unlike anything we've imagined, and he should be able to just use the documents and/or metadata without going up to his elbows into DSpace code. Abstracting a bit, I think a repo. should be well fitted to serve as a component in the organization's information architecture, not just an isolated tool. It should use other components which are useful and strive to be useful to other components. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpzWdmyKyzOE.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech