Folks,
Designing node.js thin lib (IGNITE-7777) we have the following questions.
Could you please have a look and clarify.
Thanks,
-Alexey
- Supported standard types and their type codes.
Are defined in the spec:
https://apacheignite.readme.io/docs/binary-client-protocol#data-format
But, as we see, java and .net libs (common parts which are used by
thin clients as well) support additional types and type codes, not
described in the spec. Eg. defined here:
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/GridBinaryMarshaller.java
Just to double-check - we should support the types from the spec
only. Right?
- Key-Value and SQL and Scan Queries.
The most of operations has "Flag" field in Request: "Pass 0 for
default, or 1 to keep the value in binary form."
What is it for?
Java and .net libs always pass 0. Why?
- OP_QUERY_SCAN: Filter platform.
Why is it required?
Why an app working remotely via the binary protocol should know the
exact platform where the node is running?
- Binary Type operations (register/get type name, put/get type).
What are they for?
What is a use case?
It seems possible to put data of any binary object type into a cache
w/o registering type name and structure in advance.
- OP_REGISTER_BINARY_TYPE_NAME, OP_GET_BINARY_TYPE_NAME: Platform id.
Is it a type of the node platform?
Why a remote app should know it?
Why non-identical values are used here and in OP_QUERY_SCAN: Filter
platform?
- OP_REGISTER_BINARY_TYPE_NAME, OP_PUT_BINARY_TYPE
Why the both - Type name and Java-style hash code of the type name -
are in the request? (The same for Field name and Java-style hash code of
the field name.)
Seems redundant.
- Just interesting - why it was decided that hash code should be also
calculated on a client side? Why it could not be returned by a server side?
Eg. OP_CACHE_CREATE_WITH_NAME Response can return hash code for the
provided Cache name.
That would simplify thin client implementations, guarantee
consistency/correctness of hash code calculations...
- Name/password authentication.
When will it be available in the spec?
Is there any draft we can look at?
- SSL/TLS communication.
When will it be available in the spec?
Is there any draft we can look at?
- As Denis said, we should implement a node failover algorithm
(switching to another predefined node).
Should the algorithm be the same in all thin libs?
Is it described somewhere?
We have not found it in java and .net libs. Will it be supported by
them? When?
- Is there any recommendation/suggestion how to test a node failover
case on a thin client side?
- We are going to use jsdoc comments for the API methods:
http://usejsdoc.org/
This tool, for example, may be used to generate the API spec from the
comments: https://www.npmjs.com/package/jsdoc
Any objections?
- We are going to write the lib readme/guide in the markdown format and
place it at the repo (.md file).
Is it OK? Or should we use dash.readme.io ?
- May we easily use 3rd-party components with the following licenses?
-- Apache 2.0
-- MIT
-- GNU LGPL v3
-- GNU GPL v2
Should we pre-approve somehow / notify somebody about usage of
concrete 3rd-party components?
