SAC-PDG-RPR Archives

February 2019

SAC-PDG-RPR@DISCUSSIONS.SISOSTDS.ORG

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mike Montgomery <[log in to unmask]>
Reply To:
SAC-PDG-RPR <[log in to unmask]>
Date:
Sun, 17 Feb 2019 10:59:22 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (11 lines)
Hi, Thank you for posting this. There has clearly been a lot of thought and effort on this.

I always liked the RPR-V1 solution of using separate attributes for each field, enabling attributes to be encapsulated within the right classes. It enabled focused subscription of attributes of interest and resolved the issue of irrelevant appearance/capabilities with were provided within the ES PDU - irrespective of the entity type. I do however, see and recognize that the evolution of SISO-REF-010 means that RPR-FOM can fall behind, since REF-010 updates more frequently. Clearly there is a balance needed across a range of factors such as those you summarize on the final slide of the deck and that balance is likely to be different to different users of RPR-FOM.

For me, backwards compatibility is key and so I have a preference of adding attributes for new appearance/capabilities as this means no change to the SOM for legacy federates - I would therefore put a vote towards a RPR-2 like approach and be willing to compromise on the network bandwidth.

########################################################################

To unsubscribe from the SAC-PDG-RPR list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-RPR&A=1

ATOM RSS1 RSS2