From dev-return-31559-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Thu Mar 1 16:00:19 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 5380118064D for ; Thu, 1 Mar 2018 16:00:18 +0100 (CET) Received: (qmail 73285 invoked by uid 500); 1 Mar 2018 15:00:17 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Delivered-To: moderator for dev@ignite.apache.org Received: (qmail 7581 invoked by uid 99); 1 Mar 2018 14:37:51 -0000 X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.998 X-Spam-Level: * X-Spam-Status: No, score=1.998 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xyvghknG5ncAcWxOWJEaV/GLgJYLoMqJmQ4NcLVVv4U=; b=m4SDr+XRLnVfxTVIiKCgEfRyN1tJ0tYJXUZ7LiV7wmQPqoYR/6uRQXgtBjqpzSsKo8 xpHaXcq6xyeR0dOd76cppuMjGgdkKee3a15e6fML8P9ZhklZQmCjtjzmAzt7+FNzuZ4B gQCieXSQfLvP2Hr+kx+N2CBn5zi6NRcQAMXAwquDKxX6rQxVCl8ZIt6hTtmjcMK2G8M1 V/ws1H6FuKu6DKWCx1UCJI45jPslkaZBTowJUtqgBvpTcd0TtWRGYUCe4sSyNiE87c+Y xjCBHlsXzHfVhEjAAUeGcdJdq+AYgjZNijC0gUdTuuYKP13xFtByOW1zG1Q+8OzJ8NZS nCYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xyvghknG5ncAcWxOWJEaV/GLgJYLoMqJmQ4NcLVVv4U=; b=l4wzq2S3p0w4iQ121sFE9SU6QxS3dHCArHME3A0z+o8tjLEcRgWKWsBa8DZS4WAf7r J/CXhpwHRhAzF4QZvVvoK4cNaLDCW9Qc5BuqxIQDzjP58gw1yj0WOfCwNljUM/WTiLuE Ap8plkmXMYm80KqURlYsh5mejhkH8l5tCe2cW57hTjPvaZwnLmeJtTwHvI0SmYJ5fta1 6Ue0gslHPEQPUhx+jq5/F8ZCoQmSo7nX9gzIb1UOa1RGSmancBSfEspJn1vwWzd7hCHG xmPXxpIC8RCFAs9nrEBpKNV7HcxqrejfRDbZIZNtVrFCLvo43KPjJ+LdEHRQwDxxnjcX xRrA== X-Gm-Message-State: APf1xPCtVgveiW40lBTOrZi0KhEan0okRvELrDZnJcP0w7A4KIl9fe/S KJVwu7Xo46YLz5ka4N+Japkn0Xw5qq2DiMGgEr7azA== X-Google-Smtp-Source: AG47ELtHAcjlKJKoLxQSoR9OSO9OZAUGh/C3RswKhzJCOGDr8+mUOK86HSmppwP0GhnBeTMpBe9ROith9A61cSf1VHU= X-Received: by 10.159.32.131 with SMTP id 3mr1462421uaa.166.1519915065700; Thu, 01 Mar 2018 06:37:45 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <819c5a85-0d0a-0634-afe4-14e6cc09d88d@nobitlost.com> From: Alexey Kukushkin Date: Thu, 1 Mar 2018 17:37:45 +0300 Message-ID: Subject: Re: Thin client / Binary protocol: questions To: Denis Magda Cc: dev@ignite.apache.org, Alexey Kosenchuk , Pavel Tupitsyn Content-Type: multipart/alternative; boundary="94eb2c0b6726949f6005665acdb1" --94eb2c0b6726949f6005665acdb1 Content-Type: text/plain; charset="UTF-8" Denis and All, The links you asked for: - Java thin client development branch - Code review in Upsource - Thin client documentation - Quick Start - API - Security - High Availability - Monitoring On Wed, Feb 28, 2018 at 10:44 PM, Denis Magda 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 > 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.kosenchuk@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 --94eb2c0b6726949f6005665acdb1--