added documentation template

[mdumandag]

A rendered version can be found at https://gist.github.com/mdumandag/edfe7fa2422a9220590cf0f19f8e93ed

[devOpsHazelcast]

All committers have signed the CLA.

[mdumandag]

Here is the sample of the generated markdown document. I think it can be reviewed from there easily.

https://gist.github.com/mdumandag/85dbfdaea7a8f57151bc90565126ba7d

[sancar]

@mdumandag
There seems to be problem at https://gist.github.com/mdumandag/85dbfdaea7a8f57151bc90565126ba7d#the-header

[mdumandag]

@sancar It is because of this codec documentation. https://github.com/hazelcast/hazelcast-client-protocol/blob/master/protocol-definitions/Client.yaml#L519 . Do you think that this level of detail is needed for this codec ?

[sancar]

Are we describing what Data is. For map put , it says Data as the type of the key and value.
May be we can put byte[] or, array of bytes instead of Data

Also I see Map_String_String on the types. It seems it is missed. Array of String to String mappings ?

[sancar]

I think the documentation is valuable for the ClientStatistics.
I can suggest using enclosing the docs with ``` to prevent them being processed.

[puzpuzpuz]

Does it make sense to mark some services as internal ones and exclude them from the documentation? I'm primarily talking of MC service.

[mdumandag]

I am not really sure about this. I agree that it makes some sense to hide them but on the other hand, they are publicly defined and we don't have such separation in other parts of the protocol.

I am thinking of leaving the things as it is but I can quickly change the template to ignore these if we decide to hide them.

[puzpuzpuz]

As we discuss MC service primarily, it makes sense to hear from @emre. Emre are you fine with having MC-related client messages in the generated protocol documentation?

[mdumandag]

Thanks a lot for the detailed review Andrey, I have resolved almost all of them apart from two. Could you take a look at them? Also, added Data and ByteArray to protocol data types (section 3) since we have String defined there. I believe we should mention those since all 3 of them are special, single frame types @puzpuzpuz

[puzpuzpuz]

@mdumandag changes look good to me. Thanks!

As for the second one, if we decide that we should hide internal services from the doc, we could address it in a subsequent PR.

[mdumandag]

Thanks a lot for the reviews guys. I am merging this as it is (with hiding internal services like MC). If there will be any objections to that, we can revisit this decision