Hi. I would like to build-up a graphical regression tools for board
implementation.
I try to set up things in this document. All suggestions/questions are welcome.
It is first targeted for myself. Initially it will serve as a proof builder,
to be distributed with my first attempt at implementing don's standard.
This implementation of don's standard will be targeted for readability.
I realize that the standard for unit-testing and non regression is
very high on this list. I don't feel like i can keep-up with such
a standard, unless i got a generic tool that makes the task easier.
So my project is to build a Java graphical utility to help reduce the time
of creating a new board implementation from scratch (and testing it). It will
use a communication
protocol as simple as possible as an abstraction layer between the
graphical-tool
and the board-implementation. The end goal is to be able to share a non
regression
test-suit between board-implementations.
------------------------
There are two "actors" :
------------------------
- the board-implementation (BI)
- the graphical non regression tool (GRT)
BI : It represents all the data and function for managing the board-state. It
only responds to messages.
GRT : it's a graphical tool that communicate with the BI as a controler. It
sends requests to the BI,
and interpret the answers as is needed.
The developpement will be iterative. My goal here is to share the
specification of the first iteration.
The code name of this first iteration is GRT_V1_it1. It is closely associated
to my attempt to
comply with don's specification in the most readable possible way (code name
BI_V1_it1)
--------------------------------------------------
There are two projects currently to be specified :
--------------------------------------------------
- GRT_V1_it1 : first iteration of the GRT project version 1.
- BI_V1_it1 : a board implementation counterpart to GRT_V1_it1 (complying to
don's standard)
++++++++++++++++++++++++++
GRT_V1_it1 specification :
++++++++++++++++++++++++++
In the first iteration GRT is to be able to do the following :
+ Set up the client BI to be connected (ala GOGUI with GTP_clients)
+ Propose to the user a list of dataType to visualize at any time (I call
those VectKey)
+ Propose to the user a list of action to send to the boardImplementation (I
call those ActionKey)
- A typical action would be : "play a stone at x,y"
+ A simple click must enable to send an action. A parameter will be
generated, representing the position
- Typically "play a stone at" is the action and (x,y) is the parameter
representing the stone to play
++++++++++++++++++++++++++++
GRT protocol (V1 iteration1)
++++++++++++++++++++++++++++
In the first iteration :
- the GRT part only sends "requests"
- the BI part only sends "responses"
there are two data type from the communication point of view :
- element : can be viewed as a string
- list : can be viewed as a succession of elements (a list of string)
request :
+ VectKey_list {request for the list of VectKey the BI can handle}
+ Action_list {request for the list of Action the BI can handle}
+ Vect_demand Parameter1(VectKey) {request for the data associated with
VectKey given in argument}
+ Action_board Parameter1(Action) Parameter2(position) {resquest for the BI to
commit the Action at position}
responses :
+ VectKey_list Parameter1(list of VectKey) { send back the list of supported
VectKey }
+ Action_list Parameter1(list of Action) { send back the list of supported
Action }
+ Vect_response { .. see details on it ..}
------
The main difficulty is to specify how to send back the data representing the
internal state of the board implementation.
It has to be both standard and flexible. I usually have three types of data
in the internal states :
+ Global data (example : player whom it is to make a move, current score
evaluation)
+ Whithout edge per intersection data (example : The black and white stones
on the board. Without taking into account the edges)
+ With edge per intersection data (example : The black and white stones, the
empty intersection, the edge intersections)
Then there is the problem of the board_size. In the first iteration, it is
the responsibility of the BI only to know
about the board size.
Here how i chose to represent a Vect_response :
Prequel_size (an integer)
Postquel_size (an integer)
Square_size (the usual board size to be multiplied by itself. Example 9 for
9x9)
data : a list of elements
The Prequel_size=n indicate that the n first elements should be "ignored" (or
considered as global data)
The Postquel_size=n indicate that the n last elements should be "ignored" (or
considered as global data)
The Square_size enable to format correctly the elements between Prequel_size
and Postquel_size
Example (for a 3x3 board)
Prequel_size=2
Postquel_size=1
Square_size=3
data :
0 0 (prequel)
+ X O
X + +
+ + +
0 (postquel)
-----------------------
Message representation
-----------------------
Obviously messages are made of the following :
First element : message_code
parameters : parameter_data
I want the BI part of the protocol to be as easy as possible to implements.
So the BI part, i want to be really straight forward. For example, i'd like
to avoid the whole \n problematic of the GTP_protocol
That's why i choose the following separators :
| (pipe character as the standard element separator [to be always present at
the end of an element)
|| (two pipe character as the standard list termination)
||| (triple pipe character as the standard message termination)
Note that in practice, the final element of a list that end a message will
look as following :
element||||||
the first | is the element termination
the || next are the end of list
and the ||| then are the end of message.
It's not 100% readable, but the goal of the protocol is not to be readable,
it is to be as straight forward as possible
(and very easy to implement on the BI size).
PS : i have to stop there for now. I realize that i have still to precise how
the "position" parameter works.
_________________________________________________________________
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger !
Téléchargez-le maintenant !
http://www.windowslive.fr/messenger/1.asp_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
