CommitterPhoneConf10Nov2004

From DSpace Wiki

Notes from committer call 10-Nov-2004 (11-Nov-2004 Aus)

Jim, Richard J, Gabriela, Scott, Richard R, Ralph, Rob

[edit] DSpace 1.2.1

Permissions bug seems the only showstopper. 1.2.1 beta 2 by the end of this week, 1.2.1 next week with a fix for the permissions bug Jim has managed to get crond compiling docs each night (how to access?)

[edit] Potential multi-repository change to DSpace 1.x

Don't need separate Tomcat instances -- .war's just fine Richard J has 3 instances running just fine Gabriela has 2 instances running using 2 Tomcat instances Richard R: Need more details, test to do with memory consumption Jim: Would be good to have this done in a 2.0 context

* Rob to reply, suggesting some experiments to see if that will work until 2.0

[edit] DSpace 2.0 process

People happy with the approach lined out in email 'DSpace 2.0 process thoughts'

Ralph: Need to flesh out infrastructure more. E.g. Cocoon as container - more details about requirements and how that would work, so we can make a decision

Jim: Should decide which standards and what tiers first, then we can decide on tools. Consider how people are going to want to build applications? DSpace an application vs a toolkit FEDORA-style?

Scott: Interested to look at some of the FEDORA work -- they have a form of AIP in there

Ralph: Would be good to approach FEDORA people about that, but need some clear requirements

* Richard volunteers to have a look at FEDORA, particularly the storage side, and put together a high-level set of requirements to get the ball rolling

Rob: have some good ideas, not sure if they've been communicated via docs and email effectively, hence prototype

Discussion about framework/toolkit approach vs application. Consensus we definitely need to maintain the 'works out of the box' aspect of DSpace. Proposal to accumulate requirements so that we can be sure that a base DSpace 2.0 fulfills our basic requirements.

* Rob to set up a page so that each of us can put down the requirements/features/use cases that we find essential in our Dspaces

Discussion of some of the basic areas:

* Generalised workflow component (Ralph interested)
* Standard remote API interfaces get built on top of
* Extensible APIs?
* Internationalisation
* Information model (FEDORA relevant)

Ralph: Should look at IMS digital repo definitions (reference?)

[edit] Work over next few months

Jim: Hoping to start a second asset store prototype

Ralph: Thinking about versioning -- how CVS (or subversion or ARCH) could work as an asset store

Scott: Interested in looking at providing ingest services