Difference between revisions of "V4 2nd Design Meeting Notes"

From EPICSWIKI
 
m (Meeting Notes Monday 11th)
Line 1: Line 1:
== Design Homework ==
== 2nd Design Meeting Notes ==


Create a design, possible interfaces and use cases for DA Vampire modules. I.e. plug-ins that get included between the database and the CAS. A service registers into the event manager and gets called through callback when a value for a certain value changes. It can interpose the DA interface when it wants to add properties to a channel.
=== Who is the customer? ===
 
As there are no big machines coming up and lots of existing installations, V4 will be targeting the whole community.
 
=== Compatibility and conversion issues ===
 
V4 will not support 68k processors under Tornado2, only under RTEMS. (There might be memory footprint issues, though.)
 
Lower limit: 8MB/68k or 16MB/coldfire - i.e. must support small and embedded systems.
 
Gateways will be used to convert CA connections between V3 and V4 within one system.
 
We should provide a set of asara records (asara = as similar as reasonably achievable) providing V3 behaviour that can be used for automatic conversion of existing V3 databases.

Revision as of 14:48, 11 July 2005

2nd Design Meeting Notes

Who is the customer?

As there are no big machines coming up and lots of existing installations, V4 will be targeting the whole community.

Compatibility and conversion issues

V4 will not support 68k processors under Tornado2, only under RTEMS. (There might be memory footprint issues, though.)

Lower limit: 8MB/68k or 16MB/coldfire - i.e. must support small and embedded systems.

Gateways will be used to convert CA connections between V3 and V4 within one system.

We should provide a set of asara records (asara = as similar as reasonably achievable) providing V3 behaviour that can be used for automatic conversion of existing V3 databases.

Retrieved from "https://wiki-ext.aps.anl.gov/epics/index.php?title=V4_2nd_Design_Meeting_Notes&oldid=379"