|
From: Carcassi, G. <car...@bn...> - 2010-09-20 23:00:40
|
> I am responding from the point of view of the "data source", i. e.
the
>source that provides actual data rather than other data like averaged,
>etc. Thus I mean a source like EPICS V3 or pvAccess or a relational
>database.
Then you already have the spec. It's the DataSource object in PVManager.
There is an implementation with the SimulationDataSource. I will provide
the implementation epics 3. The data interfaces are the one defined.
What are you missing?
Gabriele
-----Original Message-----
From: Marty Kraimer [mailto:mrk...@co...]
Sent: Monday, September 20, 2010 7:53 AM
To: epi...@li...;
pvm...@li...
Subject: Re: [Pvmanager-devel] user data interface: Single complex
interface vsmultiple simple interfaces
I am responding from the point of view of the "data source", i. e. the
source that provides actual data rather than other data like averaged,
etc. Thus I mean a source like EPICS V3 or pvAccess or a relational
database.
I want to see Java interface definitions that must be implemented by the
data source.
What should appear in these interfaces?
There could be something like:
connect(String pvName, String properties, ConnectCallback
connectCallback, ExceptionCallback exceptionCalllback);
and also
connect(String[] pvnames,String properties, ConnectCallback
connectCallback, ExceptionCallback exceptionCalllback);
What is properties? This is some combination of things like
"value,alarmSeverity,alarm???,display,controlLimits,alarmLevels"
The data source should be responsible for creating a container for
holding the data.
There must be methods to get/put/monitor data.
For a put pvManager puts data into the data container and calls a put
method.
For get and monitor the data source puts data into the data container
and delivers it to pvManager.
For a connect instance only a single get or put or monitor can be active
at the same time.
I DO want a complete spec of the interfaces that must be implemented by
a data source. The pvManager client may not (perhaps should not) be
aware of these interfaces but pvManager must be able to call these
interfaces based on what the client requests.
On 09/19/2010 01:51 PM, Carcassi, Gabriele wrote:
> Back from vacation.
>
>>> Right now, we are assuming to have the whole thing, because most of
> the
>>> time that's what we are going to use for display.
>> IMHO that design has the wrong default.
> This triggers a more general discussion of the purpose of PVManager.
>
> One of the reason I am writing PVManager is to be able to prepare
higher
> level structures. So:
>
> PVManager.read(tableOf(column("BPMS", pvDoubles(bpms)), column("Magnet
> current", pvDouble(pwrSplyRB)).atHz(1)
>
> Would get all the values of the bpms and the power supply, put them in
a
> table, and give me the table at 1 Hz. Now, assume that when I assemble
> the table, I only care about the value. So all those pv doubles should
> be value only, and we can optimize by only reading the value.
>
> Here is the thing: I don't want the user to have to specify _over_ and
> _over_ that those variables can be value only. It should be up to
> whoever provides the 'column' operator to specify what type it needs.
So
> parent operator must be able to set a hint to its arguments.
>
> What we actually want is to specify the metadata on the final
> expression, for example, we may have:
>
> PVManager.read(pvDouble("epics://mypv")).withMetadata(Alarm.class,
> Time.class).atHz(1); PVManager.read(sumOf(pvDouble("epics://mypv1"),
> pvDouble("epics://mypv2")).withMetadata(Alarm.class,
> Time.class).atHz(1);
>
> Now we have that the client simply specifies what bits and pieces he
> needs. In the first case, what happens is that the datasource just
> connects to the bits and pieces it needs, optimizing network traffic.
> But the second case does more: it tells the sumOf operator that it
does
> not need the display ranges, so it can tell the arguments not to get
> them but also it knows not to compute them. Using the class tokens we
> can enforce that the final type implements those metadata interfaces.
>
> The reason we need something like this is because the relationship
> between the metadata of the computation and the metadata of the
> arguments can be complicated. For example, let's say I have an average
> operator, and I want to redefine the minor/major alarm based on the
> expected sigma calculated from the individual ranges. In this case,
even
> if I just want the alarm of the average, I will need to get the alarm
> ranges of all the elements.
>
> Ok, so I hope this at least gives an understanding of the problem
space
> I am trying to solve. I am actually deliberately _not_ trying to solve
> this particular problem _now_: it's an optimization. I first want to
> make sure that the basic elements of the infrastructure are there,
that
> the API is easy to use and reliable (connections are closed, things
> don't hang, memory is de-allocated as soon as possible, reasonable
> performance in the worst case, ...). I think I have enough places to
add
> those kind of performance tuning later (the pvManager always gets and
> expression, so there is plenty of ways those expressions can be
> enriched).
>
> But, I understand that people might not be satisfied with a simple
"I'll
> get there when I get there"... and maybe that's the problem? Is it
that
> you guys want to at least have a full spec on paper (even if it's not
> what I currently distribute as the working code in pvManager) so that
> you get a sense of how all the pieces that you are working on are
going
> to fit in the future?
>
> Gabriele
>
------------------------------------------------------------------------
------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Pvmanager-devel mailing list
Pvm...@li...
https://lists.sourceforge.net/lists/listinfo/pvmanager-devel
|
