NDT-DEV email list created

[Will Hawkins <>]

Sebastian,

Thanks for doing all this great work. I will review your changes and
provide feedback as soon as possible!

Thanks again!
Will

On 05/13/2014 10:03 AM, Sebastian Kostuch wrote:
> Hi again,
> I have commited some changes on Issue145 branch where you can see my
> first attempt to convert currently sent
> messages as JSON ones. At this moment only tests specific methods have
> been changed so there are still messages
> that need converting what is my next goal. Meantime please feel free to
> review current code and every feedback
> will be very appreciated.
> 
> Please note that messages will be sent as JSON only if client sends
> extended login message, otherwise it will still
> use old format (C client is implemented to support it so you can test
> changes and verify that it works how it should).
> 
> I have used Jansson library <http://www.digip.org/jansson/> for
> encoding/decoding messages so it is required to install it on your
> system in order
> to compile program without errors.
> 
> Regards
> Sebastian
> 
> On 23.04.2014 14:02, Sebastian Kostuch wrote:
>> Hi
>> according to last discussion about changing messages to JSON I have
>> created appropriated
>> ticket related to it. I would like to propose little more detailed
>> information about format of
>> such message.
>>
>> I think that it would be good idea to change all possible messages to
>> use JSON (not
>> only the ones we expect will change in future).
>> While watching currently sent messages I have observed that they could be
>> divided into three sections:
>> 1. Empty or containing only one value messages (such as the ones sent
>> along with finalize
>> message or these with port numbers/error values)
>> 2. Messages formatted with pairs <variable name>: <variable value>
>> used mainly when
>> sending single Web100/10g variable
>> 3. Messages containing more than one variables formatted as above or
>> containing only
>> number values separated by specific character
>>
>> My idea is to format these messages using JSON as follows:
>> 1. Empty message will contain empty object ("{}") and these with only
>> one value will look
>> like this: "{ msg : value }" and clients will obtain it using "msg"
>> key. This way it would be easy
>> to add another values to such message in future if necessary.
>> 2. Something similar as to { msg : value } map but keys will be named
>> the same as
>> <variable name> and "value" will contain only actual variable's value.
>> 3. Here I think it would be good idea to separate each variable value
>> and contain it
>> within JSON as separated key/value pair (simply divide it to look like
>> this presented in point 2).
>> With messages containing variables names it is easy but what about
>> when message looks like
>> this (in middlebox test it is used such way): value1;value2;value3 ?
>> Then we don't have variable's
>> names so it isn't obvious how to store such value in map (which key to
>> use?). So what about naming
>> such values with appropriated keys which will be documented in our
>> wiki? I dislike idea of formatting
>> such messages as they are currently as it would bring troubles in
>> future similar to the one I was
>> facing when trying to add next value to such string.
>>
>> What do you think about such transition? Is it proper way to encode
>> our current messages within JSON
>> or do you see it another way? Looking forward to your feedback and
>> feel free to ask if anything isn't
>> clear :).
>>
>> Regards
>> Sebastian
>>
>