RE: VDCT Support

["Rees, NP \(Nick\)" <nick.rees@diamond.ac.uk>]

Title: Message

All,

This is getting irritating. There is something, somewhere, that is wrecking my links (at least as I see them when the message gets back to me). The last part of the URL should be "title=VDCT_Bugs_and_Features_Page".  Something is wrapping the last word. I am encoding this email as HTML to try and get around this and I hope everyone can work it out now.

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

-----Original Message-----
From: Rees, NP (Nick)
Sent: 06 July 2005 16:41
To: tech-talk@aps.anl.gov
Subject: RE: VDCT Support


Sorry all, the correct link is:

http://www.aps.anl.gov/epics/wiki/index.php?title=VDCT_Bugs_and_Features_Page

(I left off the last word). If anyone wants a spreadsheet giving the details, I can email that separately.


Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

-----Original Message-----
From: Rees, NP (Nick) [mailto:nick.rees@diamond.ac.uk]
Sent: 06 July 2005 16:01
To: tech-talk@aps.anl.gov
Subject: RE: VDCT Support


Hi,

Thank you to everyone who responded to my last post on VDCT support. I found that the adoption of it has varied, and that the groups that haven't adopted it widely are largely sitting on the fence because it has a number of irritating bugs - particularly for those wanting to use it as a replacement for a schematic capture tool like Capfast. It is basically a reasonable replacement for GDCT, but not for Capfast, yet.

This corresponds to my perception - and I would like VDCT to become more widely used than this. I feel it is important that we have a well-defined ASCII database file format, so many tools can parse the file, but only one standard DCT, so that we can develop it in conjunction with other EPICS developments, so that the toolset matches the base developments. VDCT is the only contender on the latter front, and so it needs to be made good enough - before we start enhancing it with new features (for example, developing the database file format for version 4). In particular, in the future I feel that we need a hierarchical tool to enable us to develop standard devices, so that we can develop a good interface to high level applications.

As a result of all this I have:

1. Drawn up a consolidated list of bugs and feature requests and put them on the Wiki. 2. Visited Cosylab last week to discuss the effort required to implement various requests.

The consolidated list is at: http://www.aps.anl.gov/epics/wiki/index.php?title=VDCT_Bugs_and_Features
_Page

I believe that we, at Diamond, can now fund some of this development - specifically the items marked priority 1 and 2 on this list. I have exercised total editorial discretion in determining these priorities and if you want any input to this process now is your chance to tell me I'm wrong. Please read the wiki page and let me know if you disagree with my assessments, and please make reasonable, constructive suggestions, on how we can do this better. If you just like the way it is, it would be good to hear this too, because it helps me write a case.

Finally, one thing of note was that no-one made any offer to contribute to this project. This is probably not surprising really and I am happy to take the lead, but contributions do not have to be entirely in cash. In this case, VDCT has been developed as an open source project. I have found it relatively easy to build - and one of the items on the work list it to make it even easier. So, if you discover a problem in the future and have some Java effort available, bug fixes are always welcome...

I look forward to hearing from you all.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713