Planning

= Planning = Each site should put a list of items they want to get done. Item should be as specific as possible, and they can be grouped into category with a brief preamble. Each item should bear a MH (Must Have), SH (Should have) and NH (Nice to Have) to rate the relative degree of importance of the items to the site.

== BNL ==

Infrastructure

• (MH) Script to create a page that extract the maintainer for each plug-in and publish it to the web page
• (MH) Review main page so that it formats properly (currently main part may go below side menu)

Modularization - increase the modularization of the platform, and minimize dependencies across plug-ins (especially for the site specific functionality.

• (MH) Divide CSS Core from CSS Core Utils as previously discussed. Create a org.csstudio.core.feature (which contains mininum set of plugins, to be identified and discussed) and a org.csstudio.core.utils.feature (which contains all the plugins that are part of core). Release versions of CSS will refer to release versions of these features.
• (SH) Reorganize/cleanup the org.csstudio.platform plugin.BR -Packages that should be moved to separate plugins:BR org.csstudio.platfrom.simpledal, epicsdbfile, internal.simpledal.*, model.pvsBR -Packages that should remain in org.csstudio.platfrom plugins:BR org.csstudio.platfrom.data, internal.data, internal.logging, management, model, securestore, security, service, startupservice, statistic, util. Standardize on features - review features to make them as much as possible usable out of the box by a product developer and by a user with a generic Eclipse RCP platform.
• (SH) Create a single "Epics 3 support" feature that enables epics for all data providers (DAL, utility.pv, PVManager). The current support for the protocol must be included ad-hoc for every provider by including it in the product. There is no way that a user (non/developer) can select the applications and the protocol he needs from an update site. Given the multiple providers, that the user should not be aware of which ones each application uses, and the limitation of the eclipse plug-in system, we propose that the features install all plugins for all data providers, even if not installed. At runtime, the unused plugins would not be activated. Note that this does not preclude a product developer to avoid using these feature and referring directly to the plugins.

Use extension point to create menu contributions

• (SH) Investigate how to use them and whether it's necessary to change everything at the same (can we have a period where menu contributions are specified in the old and new way?)

CSS Build.

• (NH) incorporation of unit testing into the headless build process.
• (NH) source gathering directly from mercurial repository.

PVManager

• (MH) UI to list currently installed data source and select the default
• (NH) Interface to write data (right now, limited to monitors)
• (SH) Long-term stability tests (have PVManager run for days connecting/disconnecting PV and make sure that no memory or resources are leaked)

Displays and Widgets

• (SH) Display that can display a multiple waveform (including data composed of two waveforms, data + displacement), with linear/cubic interpolation
• (SH) Widget to compare waveforms of setpoints and readbacks
• (NH) 3D waterfall plot
• (SH) UI to change the color scheme of waterfall plot
• (MH) Better integration of waterfall plot (Widget in BOY, object contributions)
• (MH) Waterfall plot: vertical axis should be time
• (MH) Waterfall plot: change in display parameter should not trigger reconnection (and lose the cached data)

== SNS == === Platform Modularization === Create new set of org.csstudio.core plugins that are modular, independent, smaller, site agnostic, to eventually replace what's now in org.csstudio.platform:

• logging: Based on java.util.logging, because that's already there?
• java: Basic Java utilities for strings, files, ...
• ui: Utilities for SWT/JFace/Draw2D to create Dialogs, ...
• workspace: Workbench, workspace tools
• auth: Authentication/Authorization.
• cs data: Control system data types (PV name, time, alarm, values)
• remote control
• usage statistics
• DAL
• utility.pv
• PVManager

Unclear if all sites can agree which modules are essential. Ideally, we don't have to. Only include what you want:

• (MH) Be able to remove unwanted components from the GUI
• (SH) Be able to really remove unwanted components from the product

=== Live Data Interface ===

• (SH) Transition from utility.pv to PVManager? What about data types? Right now, util.PV and archivereader are very convenient because they use the same data types.

=== BEAST === See [wiki:BEAST_Plans]

• (MH) Better communication between separate setups
• (MH) Dialer
• (NH) phone system

=== BOY ===

• (SH) Web viewer for display files (RAP, possibly limited to read-only PV access)