Re: Some comments about charter

[Marty K. <mrk...@co...>]

On 09/07/2011 09:31 AM, White, Greg wrote:
> Hi All, let me respond to a few things from different people in this thread.
>
> In general, I will spend 2 or 3 weeks just getting to know the code and what's been done.
>
> Cheers
> Greg
>
>
>
> * On the python questions, after I've reviewed work done, I'll come back to you.
>
> * To my mind a binding is the full implementation of a design, standard or protocol, on either client or server side. Compare to wrapper, which is just a wrapper of the API, in the sense we know. So, a python binding of the client side encapsulates pvAccess, pvData and pvIOC. Same is true of a server side binding. A wrapper would only include the API.
>
> * License. I'm completely happy to put this work under the EPICS license, or in fact to deliberately not mention a license anywhere. I just wanted to know for sure if the work was being done under a license, what it was. Now I've seen [1], that's cool, let's go with that.
>
> * names.
> Marty wrote:
>> I do not agree that we remove pv from the names.
>> What will we have:
>>
>> data
>> access
>> IOC (or engine)
>> service
> How about evData? The troubles with pv are:
>    - PV has meaning in controls which were appropriate to EPICS v3 because EPICS v3 dealt with CPV and MPVs and so on. But EPICS v4 is specifically encapsulating things which are not PVs.
>    - With "PV" prefix, the prefix != project. The name of the project is now, I think, EPICS v4, but the prefix is pv? I'd much prefer the project being called something EPICS V and the prefix being ev. With EPICS V we get to leave behind all those years when EPICS 4 was just a committee.

Note that the prefix pv is used extensively in the code. If it is 
changed than lots and lots of code changes are required.

Marty
> * performance:
>> The test was based on V4/Java and V3/C++.
>> I can send you the result if you do not have one.
> Yes please *Guobao*.
>
> * Error logging.
> Yea, *Ralph* brings up a good point, best not to rely on pvAccess for error logging when pvAccess, or at least the system as a whole, may itself be the problem. AIDA uses the CORBA messaging system, though we use the Orbacus proprietary implementation of it. And it's true, it has on occasion told us that a client can't make contact with a server for so and so reason. The other main reason we used the messaging  system was so we could do all error handling out of band.
>
> I've thought for a long time that some syslog system would be better. Anyone have experience? I think it's important.
>
> * Windows
> Ok, can we scope windows in only for the client side for now then. That's what we did for AIDA. Worked well at least inside SLAC. Getting it out of scope was a significant boost to our early progress.
>
> * aysnStatus and area detector
> I have no idea what this is all about or the issues. i'd appreciate someone can draw it out in crayon for me.
>
> Greg
>
>
>
>
>
>
> [1] http://www.aps.anl.gov/epics/license/index.php
>
> On 6 Sep 2011, at 20:35,<jam...@di...>  <jam...@di...>  wrote:
>
>> Hi
>>
>>>> pvIOCCPP
>>>>
>>>> If areaDetector is a project then portDriver must be ported from Java to C++. This can be done before PVDatabase, support, etc are done.
>>> Ok, sounds like this is going to be a thing.
>> Bob's right that the first thing to do is the pvData mapping of NDArrays and their transport over pvAccess, so this could wait a bit.  NDArrays are on the other side of the ASYN interface, EPICSv3 Database ->  ASYN Port Driver ->  plugin layer ->  NDArrays.
>>
>>> Very simple client API means python wrapper is trivial. But please, no more bindings.
>>>
>>> (Difference between wrapper and binding is key here).
>> Sorry Greg, what is the difference?! Also I'm less into the Python now I'm looking at acquisition.
>>
>>> If windows server side is needed (Diamond?) can Diamond take all responsibility for that *James*?
>> I'm afraid many of our detectors run Windows, so I can build pvData and pvAccess. The current plan is to make the detector the client, pushing images to the storage server (Linux), so we could leave out the Windows server for now.
>>
>>>> What about vxWorks? Who? Maybe Diamond or PSI?
>> We're using more Linux and less vxWorks so not Diamond.
>>
>> James
>>
>> -- 
>> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
>> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
>> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>>
>>
>>
>>
>