-----------------

(jmo) We've made lots of progress over the last week, we are going to finally review our recommendations and decisions. We are called upon to create a road map, which says we recommend that the architecture implement features X or build using architecture X not necessarily a road map that states when and how each feature will be implemented.

(jmo) we will generate a set of:

'''Reviewed the principles....

(jmo) The core is the modules in the business logic and data storage that are mutually dependent which define the essential functions of the system and implement the data model.

(jmo) We will call it "DSpace+2.0"

Manakin

(SP) Do we branch dspace, 2.x and 1.7?

(MS) Do we leap to Manakin as our only interface.

We believe that we want to move away from the JSP interface and to a more modular interface, like Manakin, where more customizations and flexibility can be supported.

(jmo) Can we publish an anonymous version of the user survey for public consumption, (rt) this is an action item or rob.

Scalability
(ms) There was also concurrency. A wiki page is dedicated to scalability problem in DSpace.
(rr) I think it's a PR issues and that most of the issues probably addressed by 1.4 but this has not been tested yet.
(rt) We could come up with a test bed to run metrics so that we can test and state the actually scalability properties of DSpace.

(ms) We can help with the pr message but we need to know the actual scalability properties.
(rr) it would be good to add the point to the pr message, that we believe the architecture is scalable and any limitations are in implementation.

data model

(rt) we decided that open well documented standards as much as possible so that exit strategies.
(jd) I think the message we need to say about exit strategies is that we support many protocols: oai, rss, export, srw.

(ms) we need to clarify the word versions, we mean different versions of the same thing, but not items like thumbnails or other manifestations.
(gt) Maybe we should say technical corrections to items, instead of new items/works.

(ms) we can still recommend that versioning between expressions be supported by item level metadata. The UI needs to be modified such that it can produce the links in the default interface.

(??) Are we going to recommend that metadata be stored in the storage layer? / metadata will be serialized and cached when necessary.

(rt) Do we need a proposal for the concrete implementation? / How much detail does an implementation team need to be able to implement it.

(ms) should we address the requirements for the two projects? / Yes / we can cover these requirements and then rap up with the recommendations. If more is needed then we can cover these off-line.

Integration framework

(jmo) Who volunteered to investigate framework implementations? Mark, Richard, Jim, and Gram.

(ms) We are going to discuss requirements for this now.

(rr) We need reasonably fine-grained version dependency support.
(rt) There needs to be interfaces or services and configurable implementations there of.
(sp) The ability to have run-time plugin modules / No that might be too limiting, perhaps just an start up time with out recompiling. / it needs to be reconfigurable without compilation.

(rt) modules need to have their own persistent storage. / A module of the system should have a service to support storage.
(rr) Support separate update of different modules.
(rr) Fine grain module version dependency support
(jd) Do we need a purpose statement? Ability to support third party modules for DSpace?
(rt) Investigate weather framework can provide publish/subscribe framework.
(rr) Frameworks needs to be consistent with our license.
(sp) Doesn't necessarily need to be compatible with 1.x features.
(rt) Java Support
(rt) Support compatible with distributed environments or at least not preclude.
(jmo) Use open standards where applicable.
(jd) EJB should be evaluated.
(jd) If there are open standards we should address why are we not adopting those standards.
(rt) Compatibility with Manakin or interface modularity. (including other web application interface)
(ms) Should we consider frameworks used by other library related projects, such as Sakia using Spring. / Where possible leverage existing component infrastructure. / Talk to chuck about their experience with modularity frameworks.
(rt) We need to be able to have very responsive mechanism, i.e. and efficient implementation / not soap.
(rr) Implementation or development complexity should not be prohibitive.

(rr) We need a prototype of the top few framework systems. / Is this reasonable for the architecture group? / Perhaps we can draw upon the resources of the community to preform the final evaluation. / Frameworks have partisan following / Do we need to satisfy or optimize? / Could I hire an consultant to render this analysis. / This group can not determine the exact framework, but recommend items to another that would preform the final evaluation of the framework. / The big work is the interfaces and not the framework, this work can be parallel-ized. / Perhaps we should evaluate other implementations of the framework by similar applications.

(ms) The framework group should be able to produce a recommendation for one framework understanding that it will be based upon the documentation, design, and existing projects.

(ms) some group will be doing some architecture group.

(jd) The group should also produce a 'slice' that exemplify the major points for future evaluation.

(jmo) The implementation should will produce a prototype that will be evaluated based upon the 'slice' by some group?

Workflow Engine

(jmo) We need volunteers to investigate framework implementations for workflow management?

(rt) A workflow system could be used for allot more than just workflow systems, the entire life-cycle including curatorial discussions. It's an open question about what the requirements are, we do know that it need to supports what is there now.

(ms) many are the same as the framework, license, application stack.
(rt) Run-time changes will need to be supported.
(rt) should allow different workflows to be defined per community/collections.
(ms) the workflow system must support the current workflow implementation.
(rt) Should the workflow system cover the initial upload systems (describe, describe, review, license, etc). This may not need to be supported by the interface.
(rt) Should support all projected DSpace functionality for later maintenance.
(rr) Needs to be able to respond and react DSpace messaging systems (or publish/subscription).
(ms) Does the workflow engine need to include a UI component or just a back-end API? / No I don't think it should include a UI component.
(ms) It needs to be able to support post submission processes.
(rt) the workflow needs to dovetail with modularity framework.

(ms) Richard Rodgers, Richard Jones, Scott, and Gabriela have the action item to evaluate the workflow engines.

Conclusions

(jmo) reviewed the requirements and proposals.
(..everyone..) We'll need a group of three programers for a year to be able to implement these designs at a central locations. A project manager / system analysts along with several developers (3-4 people) plus the larger developer community which can provide modules to add parts.