Denis and All, The links you asked for:
- Java thin client development branch <https://github.com/gridgain/apache-ignite/tree/ignite-7421> - Code review in Upsource <https://reviews.ignite.apache.org/apache-ignite/review/IG-CR-23> - Thin client documentation <https://apacheignite.readme.io/v2.3/docs/java-thin-client> - Quick Start <https://apacheignite.readme.io/v2.3/docs/java-thin-client-quick-start> - API <https://apacheignite.readme.io/v2.3/docs/java-thin-client-api> - Security <https://apacheignite.readme.io/v2.3/docs/java-thin-client-security> - High Availability <https://apacheignite.readme.io/v2.3/docs/java-thin-client-high-availability> - Monitoring <https://apacheignite.readme.io/v2.3/docs/java-thin-client-monitoring> On Wed, Feb 28, 2018 at 10:44 PM, Denis Magda <dma...@apache.org> wrote: > Guys, please consider my five cents > > >>> - Name/password authentication. >> >>> When will it be available in the spec? >> >>> Is there any draft we can look at? >> It is still under development. Will be available in several weeks. It is >> better to skip this part for now. > > > Let's give a reference to the branch where the guys can see those changes > at the protocol level. My guess they want to know what to expect and how it > can affect the design they've been working on. *Alexey Kukushkin*, please > point out to your Java thin client branch were you already have this > functionality embedded. > > >>> - SSL/TLS communication. >> >>> When will it be available in the spec? > > > This doc explains how SSL is enabled on the server side: > https://apacheignite.readme.io/docs/ssltls > > As always, the thin client needs to establish the SSL tunneling first and > then starts sending the protocol messages. Hope this is good for the > beginning. Will be happy to answer more specific questions. > > >>> - May we easily use 3rd-party components with the following licenses? >> As a general rule of thumb it is not recommended to use any external >> libraries. The whole Ignite core is built with almost no dependencies, not >> to say about much less complex thin clients ans JDBC/ODBC drivers. IMO the >> only possible place where external dependency might be required is SSL >> support (e.g. we use OpenSSL for ODBC). > > > I wouldn't discourage Alexey from using 3rd party libs taking Ignite core > as an example. Ignite optional libs use 3rd party libs a lot. Take our REST > protocol for instance that uses Jetty and not based on its own HTTP server > implementation. So, I would alter the rule of thumb a little bit - if it > takes weeks to develop a functionality already available in a 3rd party lib > then let's go for the 3rd party. > > Here is a list of licenses that can be included in Ignite without any > extra permissions or licensing concerns: https://www.apache. > org/legal/resolved.html > > According to the doc you're free to use Apache 2.0 and MIT, but LGPL code > can't be delivered within Ignite. > > -- > Denis > > On Wed, Feb 28, 2018 at 2:32 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > >> Hi Alex, >> >> >>> Just to double-check - we should support the types from the spec only. >> Right? >> Please provide the list of types you are in doubt of >> >> >>> - 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? >> Please see IgniteCache.withKeepBinary method. For SQL this flag has no >> effect. For complex SCAN queries with filters this defines whether with >> pass real objects or binary objects to the filter. >> >> >>> Java and .net libs always pass 0. Why? >> There is no Java client at the moment. As far as .NET, it doesn't support >> binary mode at the moment. >> >> >>> Why an app working remotely via the binary protocol should know the >> exact platform where the node is running? >> Because if node is started from .NET, you may execute both Java filters >> and >> .NET fitlers on it. This flag defines what kind of filter is passed. >> >> >>> - Binary Type operations (register/get type name, put/get type). >> >>> What are they for? >> >>> What is a use case? >> Please get familiar with binary type concepts, especially binary metadata: >> https://apacheignite.readme.io/docs#binaryobject-type-metadata >> >> >>> - 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? >> Because this is inefficient - we would have to rebuild binary objects on >> the server side. Instead, it is better to implement pretty simple routine >> for hashcode calculation inside every client. >> >> >>> - Name/password authentication. >> >>> When will it be available in the spec? >> >>> Is there any draft we can look at? >> It is still under development. Will be available in several weeks. It is >> better to skip this part for now. >> >> >>> - SSL/TLS communication. >> >>> When will it be available in the spec? >> This is not part of protocol specification. Please refer to .NET client >> where it is already implemented. *Pavel*, do we have docs for this? >> >> >>> - 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? >> It is still under development, will be ready in 1-2 weeks. Please skip for >> now. Yes, it is better to have the same algorithm on all clients for the >> sake of consistency. >> >> >>> - 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 ? >> All our documentation is hosted on readme.io. There should be no >> exclusions. *Denis*, could you make sure that necessary spaces and >> permissions are set up? >> >> >>> - May we easily use 3rd-party components with the following licenses? >> As a general rule of thumb it is not recommended to use any external >> libraries. The whole Ignite core is built with almost no dependencies, not >> to say about much less complex thin clients ans JDBC/ODBC drivers. IMO the >> only possible place where external dependency might be required is SSL >> support (e.g. we use OpenSSL for ODBC). >> >> Vladimir. >> >> On Wed, Feb 28, 2018 at 9:41 AM, Alexey Kosenchuk < >> alexey.kosenc...@nobitlost.com> wrote: >> >> > 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/igni >> > te/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? >> > >> > > -- Best regards, Alexey +7 981 156 56 47
