More generically (and perhaps a higher-level requirement), we should probably be
discussing how the project model is persisted. Databases are one solution
(which?) but, for example, a simple disk file is another solution (related to
57625, 57644, etc.).

This may be too specific too soon, but I've found persistance layers such as
Hibernate(www.hibernate.org), or others like it, to be extremely powerful.
Taking Hibernate as the example:
*Java based and therefore cross platform.
*Pretty much Database agnostic, the docs even suggest managing XML and flat
files, though I cant confirm this.
*Provides an object orientated interface to the data.
It has its foibles of course, but as a software contractor, I've found it to be
a real asset. Have developed Swing and J2EE apps using it.

Support saving entire project to database on MySQL, PostgreSQL, Oracle, Sybase,
or Microsoft SQL Server.

Include creating project database (given user id etc. with sufficient
privileges) and template within program, without requiring external utilities or
command line access.  Column and table names should reflect names displayed to
users.

As far as persistence goes, simple is best.  The model of MSP .mpp files or
OpenWorkbench .rmp files is best.  The only reason to have a database back end
is to do portfolio or program management, and that's a whole separate kettle of
fish.  I think we should start small: make a darned good project management
tool.  Then if there's a need we can expand the scope to portfolio management. 
We should design the project management tool so that it can easily be used for
portfolio management.  But remember again most of the users of this tool will be
done one-off or reasonably stand-alone projects.  For these users, a database is
overkill and would make the tool unweildly.

There's a higher-level requirement that I think we've missed which makes flat
file format not 'the best' but simply another alternative to support along with
database persistence.

That is, a project management system that allows managers to share live data is
an effective environment in which to work.

It's rather hard to support multi-user access in flat files (although
technically possible). Openplan, I believe, supports multi-user access --- but
the files have to be shared at the file-system level.

The net effect of multi-user access to a plan is that if I change start or
finish date in plan A, the manager who is co-ordinating plan B (assuming that
they are linked) can be notified if there is a positive or negative impact.

Furthermore, flat files generally dictate that the whole model is loaded into
working memory which is not necessarily the case with databases.

In summary, I firmly believe that both models can and should be accomodated in
the architecture and design.

If both models can be supported, that's great.  However I, for one, very much
like the simplicity of single-file persistence.

I am very much in favor of a flat file storage option.  If you have a single
project manager editing the plan, plus a number of stakeholders who get read
access to the plan (typically as e-mail attachments), then the single flat file
model is ideal.

Sharing and levelling resources over multiple projects, sub projects managed by
separate PMs, etc. break the flat file model.

MS Project has the ability to write to a database; I wonder how many people take
advantage of that feature.

Initial release will likely be flat file. The architecture will need to
anticipate a more sophisticated back end that uses a database (possibly as a way
to have multiple clients updating a single project on the back end server). All
I/O should be through a module or set of libraries, which can then be swapped
out for a more sophisticated DB back end without changing the code which saves
and loads the project.

We should specify a persistence layer to make the solution independent of the
actual mechanism. This would allow us to do an initial release storing to XML
files and a subsequent (or parallel) release that saves to a database.

Centralized storage as an option for project information can be useful when a PM
is managing a portfolio of projects (or several PMs doing the same thing). I
would be nice of Project Manager A was notified when Project Manager B modifed a
predecessor project that cause a change to dates.

I just started digging into OOo Base and I am quite enthusiastic about it. I am
about to set up a mock-up, as soon as it is available, it will be attached here.

A layer between the application and the data is my suggestion too.

This way it would be easy for developers to support different file formats and
connections to database(server)s.

hillerd, have you put something together yet?

I was wondering if you have considered Apache Jackrabbit for persistence? With
that your application code is totally decoupled from the persistence mechanism.
You can start with a non-database solution for an individual user and later
shift to a database backend without changing your application code.

Will consider Jackrabbit when we decide what to use for the glue between
application and file or database connection.

Thanks for the suggestion ;v)

This is a sum up of the existing comments in order to make it easier for us to
filter on existing requirements

- persistence layer should be agnostic of the actual storage engine, be it flat
  file local/remote xml, or a local/remote xml database, or a local/remote rdmbs
  solution, or even a full fledged local/remote object relational dbms solution


As for the persistance layers being mentioned

- hibernate seems a good solution, how well it integrates we will see
  afaik it also supports a xmldb backend for storage of the data, besides
  also being able to store data in for example existing rdbms solutions
  and, provided that we can implement a storage engine backend for hibernate,
  we will also be able to integrate our own, flat file format
- xindice, an apache project, runs short of developers and has not been updated
  in the near past


New Standard Required

When developing the OOPM we should have in mind that we eventually will have to
comply to the rest of the existing applications in the OOo suite, that is, we
will have to export and import valid Open Document file formats.

Therefore, the OOPM requires a new Open Document standard. This document format
must include both the project data and meta data along with provably also
editing history and project configuration data and meta data.

Reset assignee on issues not touched by assignee in more than 1000 days.

obsolete