EMUG99: adeptserver - Weininger

adeptserver

EuroMug'99, 28 October 1999, Cambridge, UK
Dave Weininger, Daylight CIS, Santa Fe, NM

Overview

Daylight will be producing a new kind of TCP/IP server called adeptserver. Originating from a discussion during the MUG99 meeting in Santa Fe, it was intended to provide a depiction tool, i.e., a utility for delivering customized 2D depictions in a distributed manner. 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.

Features

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.

adept architecture

program objects

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

depictor class

A depictor program generates coordinates
- May computed (calcxy46), retrieved (thread), ... or both (thrash)!
- SMILES to (x,y) coordinates
- SMILES to (x,y,z) coordinates
- others?
calcxy46 and calcxy47 (a.k.a. raguxy)
- calcxy46 uses the v4.6 dt_calcxy() algorithm
- computes 2-D coordinates from SMILES only
- implemented as the program calcxy46_talk
- calcxy47 is similar, but provides a more popular layout
thread
- 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
- rubicon, corina, and concord are obvious candidates

renderer class

A renderer program generates a visual representation
- renderers usually produce GIF, PICT, PostScript, etc.
- ... not always: e.g., graphic metafile formats like GOBs (draw2gob)
renderers are not limited to 2-D
- rasmol is a flexible renderer
- Many other candidates: pluto, midas, grasp, etc.
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." (same)
- adept approach: "Provide both, plus extensibilty." (hard!)

converter and reformatter classes

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.

other classes

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?

Examples

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 (see here)
- Might be useful for server management
- Provides powerful object-level extensibility (dangerously so?)

Outstanding issues

Security
- 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?
Priorities
- 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.
info@daylight.com