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/
