Changes between Version 13 and Version 14 of Java Quagents Client

Timestamp:

Sep 1, 2011 4:42:24 PM (13 years ago)

Author:

jherwitz

Comment:

--

Java Quagents Client

@@ -36 +36 @@
 ==== Client (Entity) ====
 
-The Client entity is an implementation of a QuagentEntity, which is a derived form the aforementioned Entity. It represents a Quagent in the Quake world. The Client is notable because it provides a multitude of convenience methods for executing Commands. We realize that the , so this provides a more functional paradigm for users. 
+The Client entity is an implementation of a QuagentEntity, which is a derived form the aforementioned Entity. It represents a Quagent in the Quake world. The Client is notable because it provides a multitude of convenience methods for executing Commands. We realize that the usage of the original Command execution may unintuitive for some users, so this provides a more functional paradigm. 
 
 === Commands ===
 
-The Java client is built on Command objects. These objects each represent one or more commands. Each command must first be instantiated, which sets all relevant parameters and generates necessary structures for use in data retrieval. At this point, the Command is independent of a command "executor". Once the command is constructed, it must then be attached to an executor. This may most easily be accomplished by using the Entity  
+The Java client is built on Command objects. These objects each represent one or more commands. ProtocolZero commands have a one-to-one correspondance with the commands detailed in [[ProtocolOZero]]. They do not instrument or interpret function, and may be thought of as simply wrapping the protocol commands. ProtocolOne commands, on the other hand, may have an arbitrary level of complexity, or may even not deal with quake at all! These commands may call one or more [[ProtocolZero]] commands, and adjust or interpret data to developer desire. An example may be found in CartesianSensor2D.java. Each command must first be instantiated, which sets all relevant parameters and generates necessary structures for use in data retrieval. At this point, the Command is independent of a command "executor". Once the command is constructed, it must then be attached to an executor. This may most easily be accomplished by using the Entity ''execute()'' or ''start()'' functions, the difference being that ''execute()'' blocks until the command is completed while ''start()'' does not. Once the command has completed execution, the user may access data by calling Command-specific functions. It is important to note that these functions do not block for return, so it is recommended that users use caution when executing non-periodic commands. 
+
+==== Periodic Commands ====
+
+Each Command also has an associated periodic functionality. If desired, the user may add an additional argument to the end of any constructor (or Client entity function), and the Command will execute automatically (in a separate thread) at a period of that many milliseconds. This is very useful for sensors or other queries that the user might want to be updated frequently or automatically.
 
 === ReaderThread ===
@@ -47 +51 @@
 
 === Listeners ===
+
+Multiple types of swing-like action listeners have been implemented. The user may choose to use these to achieve a reactive paradigm code style, or mix them with aforementioned styles to create a custom code style.
+
+==== Event ====
+
+==== Command Termination ====
 
 == External (User-Level) Structure ==