[evla-sw-discuss] MIB Data Port Spec revisions

[Barry Clark]

> I have a list of 4 changes that have been proposed for the
> MIB Data Port Spec (formerly known as the MIB Broadcast
> Stream Spec).  I will list them below.  Recipients of this
> message will have until COB on Wed, 10/29/2003 to comment.
> If, at that time, no strong objections to the changes have
> been received, the changes to the spec will be accepted.
> I am allowing only a short response period because all of
> these changes have already been thoroughly discussed.
> 
> 1. A revision to the DDR format has been proposed.
>     For the revised format:
>     - the Attention and Length fields have been dropped
>       (separate ports will be used instead of an Attention
>        bit, and the Length field is seen as unnecessary)
>     - the Antenna ID will be a STRING
>     - the Device ID will be a STRING

Alternative is that the antenna ID is the second last byte of the IP 
address.  Device ID would be last byte of the IP address + sequence number 
of Device within that CPU.  Has mild ad advantages for addressing things 
that there are more than one per antenna.  L302's can be unplugged and 
swapped into another slot more transparently.

> 
> 2. An alert record type will be added to the MIB Data
>     Port Spec.  The format of the alert message is simply
>     a minor variant on the DDR format - the ARRAY of
>     monitor points is replaced by a STRING containing
>     the text of the alert.  All other DDR fields will
>     be present.

Do we agree that we will generate "alert on" and "alert off" messages?
I think we need this feature for alerts that will be translated into flags.
If so I think we need a bit saying whether the alert is starting or
stopping.
 
> 
> 3. A revision has been proposed to the MONITORPOINT
>     record that consists of changing the monitor point
>     ID from a SHORT (two byte integer) to a STRING.

I support.  Making it a SHORT was my idea, and a bad one.

> 
> 4. It has been proposed that we encode DDRs in XML
>     rather than the proprietary format that is now a
>     part of the spec.
> 
> The last point deserves a bit of discussion.  Originally,
> a proprietary, in-house encoding was proposed because we
> planned to write DDRs directly to the archive, and we sought
> to keep the records as small as possible.  Now, DDRs will
> be unpacked and the contents of the fields will be used to
> fill an Oracle database.  So, the original impetus for the
> proprietary scheme has disappeared.  Rich argues that
> use of XML makes the job much easier on the client side.
> As a prototype/testbed, he has created an XML schema that
> describes the structure of a DDR.  Castor was then run on that
> schema to automatically produce the Java classes that serve
> as the basis for filling the archive database.  If we adopt
> XML as the encoding of the DDRs, then we can use the schema-
> based generation of the Java classes as an integral part of
> our approach, with changes in the DDR requiring only a change
> in the schema and Castor-based regeneration of the Java
> classes to adapt to the DDR changes.  Chunai has stated
> that the change to XML encoding of DDRs is straightforward,
> and she is quite willing to do the required work.
> 
> The use of XML in the DDR would also be consistent with the
> use of XML to describe the monitor and control points in
> a Device, and with the use of XML on the service port and
> the session port.
> 
> The current version of the MIB Broadcast Stream Spec can be
> found on the Computing Working Docs web page:
> 
> http://www.aoc.nrao.edu/evla/techdocs/computer/workdocs/index.shtml
> 
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>