From: Marty K. <mrk...@co...> - 2012-02-28 11:04:18
|
On 02/27/2012 08:22 PM, Benjamin Franksen wrote: > On Montag, 27. Februar 2012, Marty Kraimer wrote: >> On 02/26/2012 04:04 PM, Benjamin Franksen wrote: >>> All the protocol specification says (*) about the structure of requests >>> is that the specifics of a request are contained in the pvRequest field, >>> that this is user data (more specifically: a structure), and that it >>> must be accompanied by introspection data in a field named pvRequestIF. >>> >>> But it says nothing further about the request structure. A server that >>> answers to all requests with a bad status ("request format not >>> understood") must be regarded as conforming with respect to the pvAccess >>> protocol. >>> >>> I know that the pvIOC (note: not the pvData) docs have something to say >>> about how requests are constructed (http://epics- >>> pvdata.hg.sourceforge.net/hgweb/epics-pvdata/pvIOCJava/raw- >>> file/tip/documentation/pvIOCJava.html#L9251). It is clear that this has >>> been done because the request structure is not only used for pvAccess, >>> but also for direct access using the pvCopy API. >>> >>> So, is the intention here that the exact content of the pvRequest message >>> field is deliberately left unspecified? Or should the protocol spec say >>> something like "Requests have to be constructed according to<insert above >>> reference to chapter of pvIOC docs>."? >> It is deliberately left unspecified as far as PVAccess is concerned. >> >> There are conventions that are probably not well documented. >> The best description is probably in section "15.Package >> org.epics.ioc.pvCopy"of >> http://epics-pvdata.hg.sourceforge.net/hgweb/epics-pvdata/pvIOCJava/raw-fil >> e/tip/documentation/pvIOCJava.html > I have said it before: the structures described there are too complex. The > complexity is unnecessary as it results from mixing things that should be kept > separate: a convenient user interface, and the low-level core mechanism. > > The low-level core mechanism should be simple, require a minimum of post- > processing, and be as strongly typed as possible. The following should be > enough to capture what is currently implemented(*): > > structure fieldSelection > string[] path > // field options follow > > structure request > fieldSelection[] fields > // record options: > optional boolean process > // more record options... > > Note: the sourcePath field of structure fieldSelection is an array of strings > in case a field of a sub-structure is requested. Each fieldSelection selects > the whole field (including all sub fields if it is a structure); by convention > an empty fields list means all fields of the record. > > (*) I have dropped support for renaming fields in the copy. If someone can > present a convincing use case for this feature, it can be re-added as a field > option. > > A more complete list of field and record options (and their types) should be > specified. > > The above is to be understood as defining a set of types, not a single fixed > type. For instance, the process record option can be left out, and more field > and record options can be added. The server (PVCopy instance) is supposed to > handle options it doesn't recognize gracefully (ignore them, maybe issue a > warning, but not fail). Requests should fail if a field is present in the > request structure but has the wrong type. > > The user interface can offer methods to parse a single request string into a > request structure. As part of this parsing composite field names > ("field.subfield.subsubfield") are broken into an array of strings (path). > > The above is simple and general enough that it could be copied into the > pvAccess protocol spec. Can you make the changes you suggest? It means: 1) Changing createRequest in both the Java and C++ implementation 2) Changing the code in package org.epics.ioc.pvCopy. At or after the meeting at PSI you described desirable changes to pvCopy. You could make these changes at the same time. It is important that you do support the few existing conventions already used in the request string passed to createRequest These are what shows up the pvIOCJava swtshell in the createRequest field of get, put, putGet, and monitor get: record[]field(value,alarm,timeStamp) put: record[]field(value) putGet: record[process=true]putField(arguments)getField(result) monitor: record[queueSize=2]field(value,alarm,timeStamp) If those conventions are still valid I think that may be all that has to be changed. Marty > Cheers > Ben > > ________________________________ > > Helmholtz-Zentrum Berlin für Materialien und Energie GmbH > > Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. > > Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph > Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla > > Sitz Berlin, AG Charlottenburg, 89 HRB 5583 > > Postadresse: > Hahn-Meitner-Platz 1 > D-14109 Berlin > > http://www.helmholtz-berlin.de > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d |