program compatibility not required (but is proposed)
new first digit in the release number
Is there a need for a major revision?
Con: the current 4.x oopish-toolkit-based system works well
current system meets stability and performance goals
well-suited for current computational environments
there's nothing else like it available (poor competitive business case)
4.x has shown that it is flexible enough to accomodate major
functionality changes without a major revision
(e.g., combinatorial libraries, reactions, 64-bit port)
Pro: a revised system could do what 4.x does, better
the "oopish toolkit" approach was the right direction to jump
10 years ago, we won't have to backtrack to move forward
the Daylight Toolkit implementation works, but general purpose
solutions to many problems are now available which work better,
e.g., special purpose servers vs. general purpose O/S cacheing
the Thor and Merlin database interfaces are efficient, functional,
and probably adequate for most purposes, but we've learned how to
do better
Pro: a revised system could do things that 4.x cannot do
more general chirality model
graph-oriented pattern object
more general-purpose database servers
alternative/multiple organization of chemical information
support for user-defined objects and methods
Con: building a 5.x system from the ground up is a lot of work
in one sense, we'd be moving (back) onto unbroken ground
and will need to build a new set of tool-making tools
no pain, no gain
we have the resources needed, or close to it
Pro: toolmakers need the sharpest tools
although 4.x is flexible enough to do what we need, it's getting
painfully complex: development efficiency would be improved by
simplification and generalization ("object property" orientation)
large gains are possible when it comes to integration with other
systems
a revision would not only be more general but also smaller,
e.g., 100 entry points are easier to support than 1000
Daylight operates by achieving very high per-person development
efficiency; if we're going to continue this way, SOA tools are needed
Design goals
Retain current capabilities, improve performance
new computational model supports strict superset of current one
provide program compatibility (at toolkit level)
provide database compatibility (new servers can load old databases)
Increase computational scope
support broader range of chemical computations
e.g., structures with poorly-defined valence model,
non-local stereochemistry
store data in a manner independent of specific database servers
(merge archival, online storage, retrieval, and exploratory data
analysis functions)
support operation of arbitrary, user-defined, search processes
integrate with nearby information universes,
e.g., bioinformatic, genomic
Daylight Chemical Information Systems, Inc.