1. Gašper Tkačik Cosylab, Slovenia
EPICS Office HowTo
Gašper Tkačik
Cosylab, Slovenia

2. User’s viewpoint
Same L&F, common actions, data interpreted by different applications
Community knowledge (like TeX vs Word  example with colors in GUI)
Chart example - reference exchange
Scenarios: deployment, monitoring, exploration, configuration, spec. tasks
I said I won’t talk about the use case in my first talk, but I got the feeling that some things should be made clear
Started by trinity of office experience: we believe that this is beneficial, whatever kind of CS application you have -> general premises for making an application. We heard Heiko’s talk about user perspective, and this is one possible way to achieve it
Connected to the second point: currently, even if there is an excellent programmer in your team that makes an excellent application, this knowledge Is lost if he or she goes; everybody rediscovers that using clear colors for GUI is OK: but even when you discover that, there are two things about how you can do it. You can first, change your Jlabel in the code to red color. Or you can define somewhere what an alarm condition is, and make all alarms appear in read everywhere (!!) This is important because of
--) Everywhere
--) You can add other behaviours connected to alarm later on
Another example is chart
--) One way: have a chart component embedded in your application
--) Second way: have a charting application know how to chart anything
--) Why not both ways? Where is the technical problem: this is what the office framework should solve. What is the minimum amount of info I have to give to a generic charting component so that it can start charting? Is it just the channel name? A channel name and a type? A Channel name and the names of the characteristics (units etc) that it has to read? How does it know how to change the refresh frequency (What does it have to say to the communication layer).
Very important point: When I talk about office, drag and drop I.e. I talk about general mechanisms. I do not say that the whole control system will be replaced by this one workbench. NOT AT ALL: more realistic scenario is that you start with the workbench (navigator, views etc), try out things, do whatever you want, create panels such as in MEDM, save them, use them later (FIRST KIND, PANELS). Second kind, Group applications, now also possible such as in MEDM (virtual data sources, group things together, take them apart). COMPLEX APPLICATIONS, THIRD KIND, always need for manual code. Make workbench into the wizard that helps make such applications. Select the datasources and the data delivery QoS, make the code that delivers these into a script or a method.
WE DO NOT AIM TO REPLACE EXISTING FUNCS. IT MUST BE POSSIBLE (and for profis, it is even more efficient), TO USE ALL THINGS COMPLETELY PROGRAMATICALY, IN API, TO CREATE APPS.
Office functionality is a complement to traditional application functionality and API
EPICS Workshop, SLAC,

3. User’s viewpoint Name service if available, otherwise connected stuff
Define e.g. groups
Components in the main view
Menu NOT hardcoded
Scripting access from console
EPICS Workshop, SLAC,

4. Integrated Development…
EPICS
… and deployment environment
EPICS Workshop, SLAC,

5. Collecting feature requests More than ‘It would be nice’ argument?
EPICS Office - Why now
Is there a need?
Collecting feature requests
More than ‘It would be nice’ argument?
(Is there really code reuse and added value)
Is there a way?
Java
Shift towards Rich Client Platform
Collaborative tools (Sourceforge)
What is the cost?
Be afraid of the framework?
EPICS Workshop, SLAC,

6. What kind of Java is brewing…
Inversion-of-Control
AOP
Server side: great success of EJB, complexity
Client side: slow adoption (JVM, GUI, services, packaging)
OSGi
a LOT of stuff
Pure Java, Knoplerfish, Eclipse, Spring
EPICS Workshop, SLAC,

7. Eclipse for RCP OSGi Extension: Button in the toolbar
Extension point: clicking on the price
Plug-in component deployed as bundle
EPICS Workshop, SLAC,

8. EPICS Workshop, SLAC,

9. EPICS Office is possible But we need to:
Conclusions
EPICS Office is possible
But we need to:
Leverage existing frameworks in a smart (= simple enough) way
Design data-exchange core well
Project management (= Office can not be a ‘hobby’ activity)
Integration of cool stuff, tools (JEDM anyone), applications (VDCT model - suggestions)
EPICS Workshop, SLAC,