From a requirements point of view, we should make sure OOPM has the same
look and feel as the rest of the OO package. We'll also need to specify
expansion of the Open Document Format for our flat files.
From a development point of view the programmers must familiarize themselves
with the OO API's. Some general familarity with the OO code base would be
good, but I suspect it will be the API's that will be most helpful.
Once we have some architecture and design work done, it would be helpful to
have a senior designer from the OO team do a design review and offer some
comments to our design team.
Regards,
Shawn
Next, how could OOpm be integrated in OOo? This would also help in the
definition phase. Gilh, do you know which could be the "anchors" in the
API that OOpm could use to connect to OOo? Are there modules that could
be reused? So to give those of us who are experienced in software an
idea of the effort to build a demonstrator.
Dietmar
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
