First page No document Next page Last page
Control System Studio - CSS

CSS Home  ·  The CSS Idea  ·  Why should developers use CSS?

Why should developers use CSS?

Design Criteria for a new Operator Cockpit at DESY:

  • Avoid a DESY specific design to be open for a wider user/ developer base.
  • Avoid implementations which are coded to use only the EPICS channel access protocol.

Disadvantage of this approach:

  • More effort is necessary to implement a clean and robust design.
  • More effort is necessary for a generic/ common interface to control systems.

Advantage of this approach:

  • Regardless of the initial reason to put a lot of effort into the initial design. It is always advantageous. A clean implementation helps to make the code readable and understandable. Developers can easily use the provided interfaces.
  • Any implementations which are DESY specific will hinder others (developers and users) to use or integrate the developed code or applications into their environment.
  • DESY has put significant effort into the design of the core CSS, but also into each individual plugin to avoid DESY specifics.
  • Being independent of the underlaying control system protocol will open the scope for a wider user community. The plugin approach also on this level will reduce the effort to a minimum on the application level. Making protocols available by their URI serves the same purpose of configuration over implementation(programming) for the users like the approach to configure graphics for the Synoptic Display Studio.
  • Most importantly an open and attractive design will in the end attract developers to write their applications in a CSS compatible manner. In the end this will add a lot of additional functionality to the CSS application base. Compared with the additional initial investment in clean interfaces and specifications it will return the investment immediately.

Developing the 'CSS Way'...

  • ... shall always lead to a win/win situation. DESY will play it's role to make this happen.
  • Developers can use the whole CSS-core functionality and all subsequent applications free.
  • On the other hand CSS developers will share their developments with DESY - and other - developers.
  • This approach is already advantageous for the developers.
  • Even more important will be the growing rich set of applications the user will be able to choose from.

Which level of integration will serve which purpose?

CSS Compatibility Levels

Level of Integration

Type of Integration

Added Functionality

Missing Functionality


Very low

Java code wrapped into Eclipse Plugin

Plugins can be downloaded from update sites. The built in update mechanism will ease staying up to date. Application can be called from within CSS

No integration into CSS core functionality

Different look and feel for different applications


Native Eclipse Plugin

Plugins can be downloaded from update sites. The built in update mechanism will ease staying up to date. Application can be called from within CSS

No integration into CSS functionality

Eclipse Plugins come with their own menus and features. The CSS menu will be populated with a lot of 'stuff' which will confuse the operators.


Using the CSS Menu Layout

Plugins with their applications will show up on the same place everywhere:
In the Menu
In the 'show view' window
In the Help menu

No integration via contributions



Using CSS data-types to transfer data between Plugins via CSS Contributions and Drag and Drop

Complete data sets of complex data can be transferred between Plugins. Example: Archive data -> to Post Mortem Analyzer. (desirable for XAL Applications) Adding 'Information on your Fingertips' functionality. - Click on a channel and get a list of Plugins which serve channel related information.

New data types should be defined in the CSS core. This adds some overhead for the developer.


Using the CSS logging factory

Use a common logging infrastructure from the very beginning. Make use of several log levels and several log destinations: File and/or Console and/or JMS-Server

Fully integrated

Using CSS Management features

Being able to exchange (read/overwrite) preferences in your UI and headless CSS instances. Remote restart and messages. File transfer also for screen-dumps...

Highly Integrated

Using the interfaces for Authentication and Authorization

The interfaces are part of CSS core and may or may not be used. The rights management is built in and will allow access control down to the individual SWT widget.

How can the CSS core functionality be incorporated into your Applications

Rules of thumb for developers

  • Select the level of integration for your plugin from the list above
  • Use existing interfaces and extension points
  • Add new extension points whenever useful
  • Use Eclipse contributions to integrate your plugin seamlessly with other plugins
  • Use common data types (IData) to exchange data (not only strings) with other plugins
  • Localize strings in your code
  • Decouple local requirements from CSS implementations. Use interfaces to decouple.
  • Test CSS core versions and plugins on several platforms (at least Windows, Linux Mac-OS)