If you identify any potential areas where the DSpace code/architecture could do with some cleaning up, please add them here.

Stuff that definitely needs doing

• Add

  /dspace/bin

  wrapper scripts for all command-line tools

• Remove calls to

  System.exit

  from any method that isn't

  public void main(String[""])

• Remove commented-out code, especially when there's no explanation as to why it's been commented out

• Eliminate business logic from

  jsp/edit-metadata.jsp

  (and any other offending JSPs)

• Ensure all classes and methods have Javadoc comments
• Abstract out SRB support to be a plug-in rather than intertwined with file system storage code
• Oracle support: Make a build switch as opposed to having to copy over files. Also documentation cleanup.
• Cleanup Messsages.properties
  • It now has nearly 1400 lines with many redundancies.
  • More use of general tags for things like edit, remove, delete, cancel, id, action group, user and so on.
• Ensure consistent and appropriate logging throughout. Possible need to define a vocabulary of possible log statements for statistics/analysis etc.
• Abstract out the use of Handle System into a persistent identifier plugin
• Pay attention to redirects. For example, the following sequence is a little disorienting: Item page -> edit -> cancel -> Edit Items admin page.

Stuff that we should consider doing now we require JDK 1.5

• Using enums instead of

  public static final int

  s etc

• Make all Collections (Lists etc) use generics (where appropriate)

Stuff that might be pointless given the imminent incorporation of Manakin

• Fix use of CSS
• Fix formatting of JSPs

Stuff that is debatable

• Remove itemsByXXX tables - bad normalization. They can be replaced by a couple of small mods to Metadatum and Item.
  (Best check first – I think some processing may be done on the contents of those. You might not simply be able to normalise them. E.g. 'The Book of Silly Things' may appear in itemsByTitle as 'Book of Silly Things, The' for sorting/ordering purposes.)

• Collection.countItems()

  throws an

  SQLException

  , but is directly used by JSPs. This isn't following the usual DSpace servlet/JSP idiom; in general, all database access activity should be complete before control of a request passes to a JSP, so that an error is unlikely to occur halfway through rendering a page.

• Creative commons licenses go in the

  CC_LICENSE

  bundle, but a deposit license (the license that a depositor grants the host institution to redistribute/migrate an item) goes in the

  LICENSE

  bundle. Why not just

  LICENSE

  for both??
  (Wouldn't it be better to be as granular as possible - can always go from granular to general easily but the inverse not true. If we are able to distinguish between different license bundle types institutions can treat CC and site license differently if they want, and others can generalise if they wish. If you generalise all license types up front you can't go the other way without looking at filenames and content --SY)

• why do the stylesheet include

  nowrap

  directive for

  navigationBarItem

  ? If we need, we can insert

   

  s in the message. If it wouldn't be nowrapping style (along with some other styles) there could be many

  <br/>

  tags eliminated from the Messages file. If some styles must be kept nowrapping, then

  <br/>

  tags must be allowed in the message keys: it's much better to have a message

  "Primary<br/>Bitstream

  " than having 2 separate messages that by accident would be traslated independently each other.

• Should be easier to specify an alternative location for DSpace than

  /dspace

  in

  dspace.cfg

  . Perhaps other

  .dir

  properties should be permitted to be relative to

  dspace.dir

  ? Or somehow refer to it? (e.g.

  \{dspace.dir\}/search

  . Then you could just change

  dspace.dir

  to move the whole install. Done

• Clear up handling of dates in Dublin Core, and corresponding display code. Dates can only be parsed by DSpace if they're in IS08601, UTC/GMT timezone. Harvested dates might be different.

• LDAP authentication: Should have been implemented as a separate implementation of

  SiteAuthenticator

  rather than added to

  SimpleAuthenticator

  . Needs to be cleaned up as part of moving to StackableAuthenticationMethods