Project Plan And Schedule
CGP: 6/22/05; Revised 4A in accordance with discussion as of
The development of DTPF is planned in several stages. The first phase
development involves creating the core framework and 'system' level
This will also include creating some standard or utility nodes
informational/error messages, framework testing, etc.) as well as a
client application to allow testing of the client interface. The next
of development will involve creating a more full fledged client
suitable for end users and implementing nodes intended for direct use
Phase 1: Core Framework
|Create revision control
reposirory (SourceForge CVS, subversion, local?)
SourceForge project has
been established, website documents now live in CVS.
|Draft formal requirements
Draft document has been
prepared, going through stages of editing.
|Update project plans
Updated several times. This
will continue for the duration of the project.
YARP appears to provide the
basics for message passing. Combined YARP/ACE provide a very capable
API that should make it possible to avoid OS dependencies. YARP's
message container format leaves a bit to be desired, MUSCLE looks like
a good candidate for this.
|Explore OSX port
Apple seems happy to
provide information and resources to help people port to OSX. There
appears to have been some work done with YARP and Darwin (Darwin is
OSX's kernel, sometimes used to refer to the OSX UNIX environment).
MUSLCE provides handy utility functions for endianess operations. Should only be a factor
when moving data from opposite endian platforms.
|Meet with Dr. Colburn and
Dr. Shute, et. al.
Want to have some feedback on what we are doing from 'outside' parties.
|Refine requirements for
framework library, module management roster and module loading
applications to a reasonable point of completeness and stability.
Comparison to MediaKit, JMF, etc. will help with this.
||Late March /
Define some possible applications for DTPF: SenseStream
implemented in terms of DTPF, SoDiBot interfacing to the DTPF version
of SenseStream, ESMA (June 2005 NIH grant modeling).
Goal: Ensure that facilities planned for DTPF
will enable implementation of these possible applications.
Further refinement of requirements for framework
Goal: move design portions of the requirements
document into a design document.
Investigate how ACE can support our requirements.
Goal: Read ACE papers, and try using (i.e.,
compiling and running sample programs) particular ACE functionality on
Mac OS X to resolve questions. (E.g., use of Streams in ACE).
(Tasks to be completed by end of June)
Add detail to the design for (i) Roster, (ii) Nodes,
(iii) data I/O formats for Nodes (Format Models), (iv) Node parameters
(Parameter Models), (v) Plugin loader, and (vi) Buffer channel
communications (including sending/receiving messages and buffer
Goal: Create application programming interfaces
(APIs) in DOxygen, and create primary data structures in C++ for these
parts of the DTPF. (Note: By "Node parameters" I mean the
mechanism by which Nodes specify to the GUI what information a user can
change or view regarding a Node).
Some details: Roster API will include loading a
Node, unloading a Node, Node registration, querying for list of Nodes
that are presently loaded, querying for a list of Nodes that can be
loaded, querying a particular loaded Node for its input or output
format requirement, run/pause/resume/stop for a loaded Node,
establishing a communication connection between an upstream Node and a
downstream Node, querying a Node for its parameters, changing a Node's
Continued refinement of requirements for framework
Goal: Keep requirements document up-to-date
with regards to changes that arise as the design progresses.
Program, debug, and carryout component tests for wrapper
interface for use of ACE.
Goal: API specified in DOxygen, and C++
class(es) that enable use of the parts of ACE that we need.
(Tasks to be completed by end of July)
© 2005 Eric J.
Mislivec, Last Modified: 22 June, 2005