Talk:High Level Architecture: Difference between revisions
m Signing comment by LVCTaylor - "Once again..." |
Realtme101 (talk | contribs) You got it backwards friend. |
||
Line 13: | Line 13: | ||
The concept of interoperability does not exclude the use of an API standard to support interoperability. To state that a wire protocol is necessary in order to achieve interoperability is misguiding. <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:SpaceRay|SpaceRay]] ([[User talk:SpaceRay|talk]] • [[Special:Contributions/SpaceRay|contribs]]) 20:01, 15 January 2013 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot--> |
The concept of interoperability does not exclude the use of an API standard to support interoperability. To state that a wire protocol is necessary in order to achieve interoperability is misguiding. <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:SpaceRay|SpaceRay]] ([[User talk:SpaceRay|talk]] • [[Special:Contributions/SpaceRay|contribs]]) 20:01, 15 January 2013 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot--> |
||
==Disagree== |
|||
API’s are everywhere and thousands are standardized and serve only to describe one side of the data flow in this case. In the case of HLA, the standardized API connects applications to the proprietary RTI interconnect mechanism which requires all to use the same proprietary RTI, a fine example of the definition of non-interoperability among participants. The author that is trying to tell us that HLA is somehow interoperable is just plain wrong. It might be deemed data interoperable, but even that’s a stretch because the data has to flow through a proprietary network to get to the other side. If everyone on the planet used the same RTI and it was the only one, a wishful though indeed for some, we might be able to address HLA this way, but for now, we cannot and should not, else we would be misguiding indeed. The long section discussing the API standard versus a protocol standard is an opinion and is not here in support of the definition of HLA. It should be deleted or moved to the talk section. |
|||
== Protocol vs API standard == |
== Protocol vs API standard == |
Revision as of 05:59, 16 January 2013
NATO (inactive) | ||||
|
What is the area where this definition applies? For instance, would it be correct to start the article "In computing, ..." ? Notinasnaid 10:51, 3 Nov 2004 (UTC)
Interoperability Message Being Changed to Reflect a Different View
The original section titled “Interoperability Limitation” was almost completely rewritten to reflect a different view. I put it back as it was, but changed it to reflect only the raw facts. Too many people have found out the hard way that the HLA has no network standard and any given RTI implantation will not interoperate with any other, even open source ones. There is an expectation that these RTIs will in fact connect with each other by the Distributed Modeling and Simulation (DM&S) public, but alas, it’s not true and my original purpose for this section was to make that point clear. It is my opinion, watering down this meaning is wrong technical and ethically.
Closing architectures rarely benefit anyone in the long run. Researchers outside of DM&S have shown this to be true. The idea that the HLA architecture was closed in order to provide for technical innovation seems doubtful since anyone would be free to innovate regardless of the open or closed nature of the network transport. It’s a business model just like any other proprietary network transport that traded openness for market share. In the relatively small DM&S community, this seems to have been missed. — Preceding unsigned comment added by LVCTaylor (talk • contribs) 23:31, 1 January 2013 (UTC)
Once again, putting the message back in after deletion
The last editor deleted the controversial section altogether and uses this reasoning: Section deleted since it was irrelevant. HLA standard is open on the API level and is not intended to be locked into any specific way of physical data distribution The authors point, Section deleted since it was irrelevant could not be further from reality, as this point is the single greatest disadvantage to using the HLA as it is the expectation. The second part, locked into any specific way of physical data distribution makes little sense, because any RTI author would still be free to do as they wished regardless if a wire standard existed or not. Similar circumstances existed in other industries and these excuses for closed architectures were used there as well until well thought out and mature standards emerged. Case in point is the Real Time Protocol (RTP). Attempts to hide these facts only serve to highlight this issue. Other interconnect mechanisms also have “disadvantage” sections on their wiki's. This section is headed to dispute resolution. — Preceding unsigned comment added by LVCTaylor (talk • contribs) 08:22, 15 January 2013 (UTC)
Concept of interoperability
The concept of interoperability does not exclude the use of an API standard to support interoperability. To state that a wire protocol is necessary in order to achieve interoperability is misguiding. — Preceding unsigned comment added by SpaceRay (talk • contribs) 20:01, 15 January 2013 (UTC)
Disagree
API’s are everywhere and thousands are standardized and serve only to describe one side of the data flow in this case. In the case of HLA, the standardized API connects applications to the proprietary RTI interconnect mechanism which requires all to use the same proprietary RTI, a fine example of the definition of non-interoperability among participants. The author that is trying to tell us that HLA is somehow interoperable is just plain wrong. It might be deemed data interoperable, but even that’s a stretch because the data has to flow through a proprietary network to get to the other side. If everyone on the planet used the same RTI and it was the only one, a wishful though indeed for some, we might be able to address HLA this way, but for now, we cannot and should not, else we would be misguiding indeed. The long section discussing the API standard versus a protocol standard is an opinion and is not here in support of the definition of HLA. It should be deleted or moved to the talk section.
Protocol vs API standard
Whether an API standard is an advantage or a disadvantage has to judged by users of the standard and not by any individuals. The description that HLA is an API standard and does not specify any data exchange protocols is enough.
SpaceRay (talk) 20:09, 15 January 2013 (UTC)SpaceRay
Factual deletions are not ethical
To say that interoperability is the result of proprietary communications is true only in the literal sense. I see a desperate attempt to justify this idea that closed architectures are somehow characterized as interoperable. Closed architectures are by definition non-interoperable. I am not purporting that the HLA has no value, only that is not be sold to the lay public as an interoperable mechanism. I have personally known several instances where national labs used the HLA, and were surprised when that lab could not interconnect to others using the HLA because the other side used a different HLA implementation. By the way, the lay public also does not realize that the cost of a typical commercial HLA RTI middleware package is around $1,500 US. A lab with twenty workstations would have to fork over $30,000 for the privilege, only to find out that they cannot interoperate with other RTI implementations. This is the single message you continue to delete and follow with less than factual stuff that is at best an opinion. My section was factual. It is a fact, and you keep deleting it. — Preceding unsigned comment added by LVCTaylor (talk • contribs) 22:41, 15 January 2013 (UTC)