Back to SISO Website
SISO Discussion Forums

Help for SAC-PDG-WEBLVC Discussion Forum List


SAC-PDG-WEBLVC Discussion Forum List

SAC-PDG-WEBLVC Discussion Forum List


SAC-PDG-WEBLVC@DISCUSSIONS.SISOSTDS.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

SISO Discussions Home

SISO Discussions Home

SAC-PDG-WEBLVC Home

SAC-PDG-WEBLVC Home

SAC-PDG-WEBLVC  July 2017

SAC-PDG-WEBLVC July 2017

Subject:

Re: Revised EnvironmentObject

From:

Brad Dillman <[log in to unmask]>

Reply-To:

SAC-PDG-WebLVC <[log in to unmask]>

Date:

Wed, 5 Jul 2017 08:29:00 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (23 lines)

The segment number is part of RPR FOM. I included it for compatibility (so a gateway which translated WebLVC/RPR wouldn't have to make one up). I'm not sure why RPR has it, except that the segment number might just be a unique ID number for a segment? Say you wanted to insert or delete segments, you couldn't use the index in the list as an ID because that would change.

Next, what a great question! 1 variable message (EnvObj + kind) vs. 3 variable messages (PointEnvObj, LineEnvObj, AreaEnvObj). And at a great time too, before we start building out message libraries (WebLVC FOMs?).

These 3 things have a common application domain: they describe environment objects, but in different ways. From a modeler's perspective, they're similar.

But these 3 messages have different properties (geometries), as well as a few common ones (appearance properties, each of which are also optional). Area and point are more similar, Line is a little different.

To me, the biggest difference is 1 key (MessageKind) vs a composite key (MessageKind+EnvironmentObjectGeometryType). I think a single key is simpler, and more efficient from a transmission point of view (fewer properties means less overhead).

Client representations of these messages aren't affected by how we structure these messages. There's no inheritance in JSON messages and no point in having a 4th, common base message. The client programming language can decode these messages in any way the developer prefers, regardless of how we choose to structure the messages: either a single class, multiple classes or a hierarchy of 4 classes or more. The client representation can have 1 or 2 keys, doesn't affect the messages.

From a documentation point of view, it's more work to write (and maintain!) 3 messages vs. 1, unless there's a way to organize the documentation to reference common sections for common properties. Maybe we should divide the documentation into messages and JSON objects (I mean re-usable JSON objects within messages, not WebLVC Objects). I started doing this with the 'Coordinates' property. The DIS documentation is structured this way, too, so there's a precedent.

+1 for 3 objects.

+1 for breaking out environment apperance properties in the documentation (and referencing it from the 3 object messages).

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

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search SISO Discussions

Search SISO Discussions


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Discussion Forum List

February 2019
September 2018
May 2018
April 2018
March 2018
January 2018
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
March 2017
October 2016
September 2016
August 2016
July 2016
November 2015
September 2015
June 2015
March 2015
February 2015
January 2015
December 2014

ATOM RSS1 RSS2