EMUG99: adeptserver - Weininger
Daylight will be producing a new kind of TCP/IP server called
Originating from a discussion during the MUG99 meeting in Santa Fe,
it was intended to provide
i.e., a utility for delivering customized 2D depictions in a distributed
During development this summer, it evolved into a generic
program-object-based compute server which is likely to be useful for
many other functions.
The adept architecture is very simple.
adeptserver is a normal, full-blown TCP/IP server, similar in
form to thorserver, merlinserver and daytoolserver.
adeptserver communicates with clients primarily via Thor
datatrees and uses program objects to do computational tasks such
as generating and rendering pictures.
The overall system is robust, flexible and very extensible.
It is expected to meet our long-term structural display needs.
- adeptserver provides a "full blown" TCP/IP service
- robust socket connections
- separate client contexts
- logging, "keep-alive", etc.
- enterprise-wide and/or Internet-style service
- Communication is done via Thor datatrees (TDTs)
- Simplifies database integration
- Processing is done by program objects
- separate processes for robust server operation
- high-startup-cost algorithms are OK
- simplified coarse-grained multiprocessing
- All types of files may be used
- Input files such as .smi, .sd, .pdb, etc.
- Output files such as .gif, .ps, .pdf, etc.
- New datatypes (e.g., GIF) are required (no big deal)
- Not limited to "2-D molecular diagrams"
- Flexible highlighting and annotations
- Reactions are "free"
- Display of 3-D data (e.g, conformations)
- Open-ended system for the future: reaction schema, etc.
- A program object represents a running program
- separate processes communicating via "pipetalk"
- talk via string objects and do anything else they need
- support a few managment messages (version, notice, etc.)
- define their own messages
- program objects are real objects in the Daylight Toolkit
- access is architecture- and language-independent
- data interface is well-defined and "limitless"
- program objects are already fully-supported by Daylight
- merlinsmartstalk used for SMARTS searching performance
- "contrib" programs (medchemtalk, nt_echotalk, merlinbintalk, etc.)
- adept program objects read and write ASCII strings
- most read a TDT, add something to it, and write a TDT back
- other types of strings may also be used, e.g., .sd files
- A depictor program generates coordinates
- May computed (calcxy46),
... or both (thrash)!
- SMILES to (x,y) coordinates
- SMILES to (x,y,z) coordinates
- calcxy46 and
- calcxy46 uses the v4.6
- computes 2-D coordinates from SMILES only
- implemented as the program calcxy46_talk
- calcxy47 is similar,
but provides a more popular layout
- thread simply reads 2D coordinates
from a Thor database.
- The database might be corporate or commercial (e.g., spresi).
- Just $SMI and 2D datatypes are required (finesse security issues?)
- thrash is neat!
- thrash starts with a database that
thread might use
- structure is reduced to an unlabeled graph
- 2-D coordinates are stored with the "unlabeled SMILES"
- Works like thread,
but only needs a "shape match"
- 3-D generators
- Model generators can be used as 3-D depictors
are obvious candidates
- A renderer program generates a visual
- renderers usually produce GIF, PICT, PostScript, etc.
- ... not always: e.g., graphic metafile formats like GOBs
- renderers are not limited to 2-D
- rasmol is a flexible renderer
- Many other candidates:
- Rendering is non-trivial!
- Aesthetic problems can never be solved perfectly. Ah.
- One approach: "Pick one and live with it."
(works for a while)
- Another approach: "Provide maximum flexibility."
- adept approach: "Provide both, plus extensibilty."
- These classes change encoding but not representation
- Should be easy well-defined problems.
- Really, they should be easy, but sometimes they aren't.
- converters change the format of
the represented entity
- smi2tdt, sd2tdt, rosdal2tdt, etc.
- pdb2tdt, pdbdeom2tdt, pdbrasmol2tdt, pdbconcord2tdt ... ouch
- reformatters operate on the
final encoding directly
- gif2png, gob2gif, ps2pdf, etc.
- reformatters are converters of graphic object representations
- Do we need these classes?
- Perhaps this work should be done on the client.
- Lots of implementations are available (babel, mogrify, xv, etc.)
- Not currently implemented in adeptserver.
- Composite methods
- Composite methods are composed of simpler methods
- Composite methods don't need separate program objects
- E.g., a composite depiction method might be:
if molecule's 2D data is in CorpDB, use that
else if molecule's 2D data is in spresi, use that
else if molecule's shape is in CorpDBshapes, use that
else if molecule's shape is in spresi, use that
else if ringsystem(s) are in CorpDBshapes, fix those parts
else if other ringsystem(s) are in spresi, fix those parts
else if ringsystem shape are in CorpDBshapes, fix those part
else if other ringsystem shapes are in spresi, fix those parts
else compute using calcxy47
- non-graphical methods
- adept is general enough to use as a compute server
- E.g., clogptalk already exists
- Is this a good idea? Do we need new classes or not?
The adept toolkit
- The adept toolkit will not be needed for most purposes
- Interfaces will be provided (e.g., treetalker and CGI programs)
- Most customizations done with existing progob toolkit
- The adept toolkit provides powerful object-level access
- Easy to use (see here)
- Allows common functionality to be handled in a elegant manner
- Common functionality is handled elegantly
- Might be useful for server management
- Provides powerful object-level extensibility
- On one hand, it would be nice not to need passwords
- On the other, corporate types seem to like them
- In any case, we need security for progob management
- Format conversion class/method
- Should input conversion be part of adeptserver's job?
- publication quality PostScript
- new formats, e.g., Display PDF
- old formats, e.g., "ChemDraw direct"
- reaction schema
- non-graphical functionality
Daylight Chemical Information Systems, Inc.