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  March 2017

SAC-PDG-WEBLVC March 2017

Subject:

Re: questions regarding draft 0.5

From:

Ringo Wathelet <[log in to unmask]>

Reply-To:

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

Date:

Fri, 10 Mar 2017 23:07:59 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (43 lines)

Thanks for your reply.

> Good point. The ObjectBounds filter implicitly assumes you're filtering an entity object
> of some kind. This filter could use a lot more definition, couldn't it?
> For example what exactly does "... Interaction messages outside this range..." mean, anyway?
> Maybe this should be dropped from the specification, and left to be implemented as proprietary extensions?

The ObjectBounds filter for entities works well, it could remain in the specification rather than a proprietary extension.

What I was thinking for Interactions, is for example:
a MunitionDetonation or a WeaponFire Interaction message is filtered based on its Coordinates,
such that a client may not be interested in receiving these messages if there are to far away
from a given "ObjectName" (which could be moving). Note I think this is not a major issue if
such filtering is not available for Interactions. WorldBounds capture the bulk of cases.

Re: my question on Configuration of CoordinateReferenceSystem, what I was
thinking here is that just because a client has requested a change in CoordinateReferenceSystem,
it suddenly finds itself with unintended possible DeadReckonning, making the Coordinates it receives different
from what the simulation is producing.
 
> Here's a problem I'm thinking of: suppose a WebLVC client decides to publish a new object
> or interaction of which the server is unaware. It would be nice to avoid having
> to re-write the server to understand the new object or interaction.
> So how do we write filter definitions which don't require implicit assumptions
> like the ObjectBounds filter?

I think one way could be for the client to send the server "the filters", rather than cryptic
mix of messages with "all", "and" etc... to switch the server into different filtering modes.
For example, the client sends a JavaScript code block (a string) with one designated "filter" function.
The server then runs the JavaScript code with the expected function name.
This is very easy to implement in a server running on JVM, because it has a built in JavaScript engine.
Any server written in java, scala and all other languages that runs on the JVM.
For other languages, such as C++, there are also a number of good JavaScript engines that can be used.

In essence let the clients make the filters however they want, and let the server run them
on their behalf. All the server needs is the "standard" name of the function to invoke.
This function then returns true or false to filter the message.

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

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

January 2020
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