> I don't think we need an explicit reactive API in the core library.
> Observable.fromFuture bridges async to Rx easily:
Cannot immediately agree here. Observable.fromFuture is not fair
reactive Publisher because computation for wrapped future most likely
starts before any subscription. While in general Publisher has an
option do nothing before subscribe() is called. Another important
matter is backpressure, I hardly imagine how can it be implemented for
Observable.fromFuture.
And nowadays reactive APIs are not just fancy stuff for hipsters. I
suppose we should consider popular API styles beforehand.
2021-07-13 10:44 GMT+03:00, Ivan Daschinsky <ivanda...@gmail.com>:
> Pavel, actually, setters in builder is not ok. But as for me, the better
> approach is something like this:
>
> IgniteClient client = IgniteClient.start("127.0.0.1:10800")
>
> or
>
> CompletableFuture<IgniteClient> client =
> IgniteClient.startAsync(IgniteClientConfiguration.builder()
> .addresses("127.0.0.1:10800)
> .timeout(5000)
> .build())
>
> I suppose that should be a few simple shortcuts to start client as is and
> immutable IgniteClientConfiguration.
>
> My point is:
> 1. It is easier to understand (creation is within IgniteClient, easy to
> find and very predictable, Ignition is not intuitive, but may be fun and
> eastern egg like)
> 2. Immutable configuration -- harder to make a mistake when extending
> configuration (you must always copy config if it is mutable), less syntaxic
> garbage ('set' prefix is not needed)
>
>
>
> вт, 13 июл. 2021 г. в 09:55, Pavel Tupitsyn <ptupit...@apache.org>:
>
>> Val,
>>
>> Ivan D has convinced me above to try the builder pattern, which is used
>> by
>> many other drivers (Redis, Mongo, etc).
>> With IgniteClient class in ignite-client module:
>>
>> Ignite client = IgniteClient.builder()
>> .setAddresses("127.0.0.1:10800")
>> .setTimeout(5000)
>> .build();
>>
>> What do you think?
>>
>> On Mon, Jul 12, 2021 at 10:57 PM Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>> > Pavel,
>> >
>> > If Ignition is the single entry point, it needs to have access to the
>> > server node instance, so it needs to depend on ignite-runner.
>> > Therefore,
>> > including Ignition in ignite-client means that ignite-client depends on
>> > ignite-runner, which we cannot have.
>> >
>> > -Val
>> >
>> > On Sat, Jul 10, 2021 at 4:17 AM Pavel Tupitsyn <ptupit...@apache.org>
>> > wrote:
>> >
>> > > Val,
>> > >
>> > > My suggestion is to have Ignition class in ignite-client module.
>> > >
>> > > On Fri, Jul 9, 2021 at 11:01 PM Valentin Kulichenko <
>> > > valentin.kuliche...@gmail.com> wrote:
>> > >
>> > > > Pavel,
>> > > >
>> > > > Ivan actually brings a good point. While the client is in a
>> > > > separate
>> > > > module, Ignition (if we make it static) will have to depend on both
>> > > > ignite-client and ignite-runner, and we will have to ship it along
>> with
>> > > the
>> > > > client. This indeed creates an uber-jar, so we can't really have a
>> > single
>> > > > entry point, unfortunately.
>> > > >
>> > > > I'm not sure what is the best way to proceed here. Let's think it
>> over
>> > > and
>> > > > see if there are any suggestions.
>> > > >
>> > > > -Val
>> > > >
>> > > > On Fri, Jul 9, 2021 at 6:31 AM Pavel Tupitsyn
>> > > > <ptupit...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > > why thin client should be in core module
>> > > > >
>> > > > > It will be in a separate module (ignite-client).
>> > > > > I was talking about "core library" as a primary set of modules
>> > > > > that
>> > we
>> > > > > ship.
>> > > > > Integrations with 3rd party libraries and frameworks can be
>> > > > > shipped
>> > as
>> > > > > extensions.
>> > > > >
>> > > > > Anyway, let's postpone the discussion of Rx and Kotlin.
>> > > > > The main goal right now is to implement the most basic Java thin
>> > > client.
>> > > > > CompletableFuture is the primary way to deliver async APIs in
>> Ignite
>> > > 3.0,
>> > > > > other things can be added later.
>> > > > >
>> > > > > On Fri, Jul 9, 2021 at 3:37 PM Ivan Daschinsky <
>> ivanda...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > > I don't think we need an explicit reactive API in the core
>> > library.
>> > > > > >
>> > > > > > Have you ever thought about why thin client should be in core
>> > module?
>> > > > Why
>> > > > > > we do the same thing as we did in ignite 2.x? In the days of
>> cloud
>> > > > native
>> > > > > > we still think about large uber-jar with everything?
>> > > > > >
>> > > > > > > Same story with Kotlin, it works with CompletableFuture.
>> > > > > > Users don't want to code by theyselves, they want to use ready
>> and
>> > > > > complete
>> > > > > > clients. Please, don't underestimate kotlin, kotlin coroutines
>> and
>> > > > > reactive
>> > > > > > streams. They are all the first class citizens in spring 5 for
>> > > > > > 3
>> > > years
>> > > > > >
>> > > > > > пт, 9 июл. 2021 г., 14:43 Pavel Tupitsyn
>> > > > > > <ptupit...@apache.org>:
>> > > > > >
>> > > > > > > > You forget about reactive api
>> > > > > > >
>> > > > > > > I don't think we need an explicit reactive API in the core
>> > library.
>> > > > > > > Observable.fromFuture bridges async to Rx easily:
>> > > > > > >
>> > > > > > > Observable.fromFuture(client.putAsync(k, v)).flatMap(...)
>> > > > > > >
>> > > > > > > Same story with Kotlin, it works with CompletableFuture.
>> > > > > > >
>> > > > > > > On Fri, Jul 9, 2021 at 1:31 PM Ivan Daschinsky <
>> > > ivanda...@gmail.com>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > You forget about reactive api :)
>> > > > > > > >
>> > > > > > > > And whats a problem with discocerability?
>> > > > > > > >
>> > > > > > > > var syncApi = client.sync();
>> > > > > > > > syncApi.put(k, v);
>> > > > > > > >
>> > > > > > > > var rxApi = client.reactive();
>> > > > > > > > rxApi.put(k,v).flatMap(res -> ....);
>> > > > > > > >
>> > > > > > > > And sync, async and reactive is not enough, it is good idea
>> to
>> > > > > support
>> > > > > > > > kotlin coroutines also :)
>> > > > > > > >
>> > > > > > > > пт, 9 июл. 2021 г., 13:26 Pavel Tupitsyn <
>> ptupit...@apache.org
>> > >:
>> > > > > > > >
>> > > > > > > > > Ivan D.,
>> > > > > > > > >
>> > > > > > > > > > container of properties
>> > > > > > > > >
>> > > > > > > > > What is a container of properties?
>> > > > > > > > > As a user, I want a simple way to start a client and
>> perform
>> > > > > > > operations.
>> > > > > > > > >
>> > > > > > > > > I don't want anything confusing and complicated like
>> > > > > > > > > Netty
>> > > > > Bootstrap.
>> > > > > > > > There
>> > > > > > > > > might be a reason for Netty to be this way - it is a
>> > low-level
>> > > > > > library.
>> > > > > > > > But
>> > > > > > > > > Ignite is not.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > > separate facades for sync, async
>> > > > > > > > >
>> > > > > > > > > Strongly disagree with this idea. It hurts API
>> > discoverability.
>> > > > > > > > > As a user, in my IDE I type "igniteTable.get" and see a
>> list
>> > of
>> > > > > > > > suggestions
>> > > > > > > > > like get, getAsync, getAndPut, getAndPutAsync.
>> > > > > > > > > I don't want to have a separate interface and a separate
>> > > variable
>> > > > > to
>> > > > > > > deal
>> > > > > > > > > with sync and async methods.
>> > > > > > > > >
>> > > > > > > > > Not sure what's the problem with documentation - can you
>> > > > elaborate
>> > > > > > > > please?
>> > > > > > > > >
>> > > > > > > > > On Fri, Jul 9, 2021 at 12:51 PM Ivan Daschinsky <
>> > > > > ivanda...@gmail.com
>> > > > > > >
>> > > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > > > Pavel, actually I suggests to separate container of
>> > > > > > properties(client
>> > > > > > > > in
>> > > > > > > > > > lettuce) and actual connection or connections (stateful
>> > > > > connection
>> > > > > > in
>> > > > > > > > > > lettuce). Actual connection initialization could be
>> > > > > > > > > > sync
>> or
>> > > > > async,
>> > > > > > it
>> > > > > > > > > > doesn't matter. It can be Ignition#startClient or
>> > > > > > > > > > Ignition#startClientAsync, but I'd prefer lettuce
>> approach
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Also, it would be great to have separate facades for
>> sync,
>> > > > async
>> > > > > > and
>> > > > > > > > > > reactive api. Mixing all of them in one interface is a
>> > > > > > documentation
>> > > > > > > > > > nightmare.
>> > > > > > > > > >
>> > > > > > > > > > пт, 9 июл. 2021 г., 11:55 Pavel Tupitsyn <
>> > > ptupit...@apache.org
>> > > > >:
>> > > > > > > > > >
>> > > > > > > > > > > Ivan P., Ivan D.,
>> > > > > > > > > > >
>> > > > > > > > > > > I don't think it makes sense to separate
>> IgniteConnection
>> > > and
>> > > > > > > > > > IgniteClient
>> > > > > > > > > > > like Lettuce does,
>> > > > > > > > > > > because IgniteClient will maintain connections to
>> > multiple
>> > > > > server
>> > > > > > > > nodes
>> > > > > > > > > > > automatically,
>> > > > > > > > > > > and the number of connections can grow and shrink
>> > > > dynamically.
>> > > > > > > > > > >
>> > > > > > > > > > > This is required to support dynamic clusters together
>> > with
>> > > > > > > partition
>> > > > > > > > > > > awareness.
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > > Why not to make async variant of connection
>> > > > > > > > > > >
>> > > > > > > > > > > Ignite API will (eventually) have both sync and async
>> > > > variants
>> > > > > of
>> > > > > > > > every
>> > > > > > > > > > > method, where applicable,
>> > > > > > > > > > > including the method that connects the client to the
>> > > cluster.
>> > > > > > > > > > >
>> > > > > > > > > > > On Fri, Jul 9, 2021 at 9:55 AM Ivan Pavlukhin <
>> > > > > > vololo...@gmail.com
>> > > > > > > >
>> > > > > > > > > > wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > > Val,
>> > > > > > > > > > > >
>> > > > > > > > > > > > > Ignition IS the entry point to Ignite, so I'm not
>> > sure
>> > > I
>> > > > > got
>> > > > > > > your
>> > > > > > > > > > point
>> > > > > > > > > > > > :)
>> > > > > > > > > > > > > Either way, please feel free to give your
>> suggestions
>> > > for
>> > > > > an
>> > > > > > > > > > > alternative
>> > > > > > > > > > > > name if you have any.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Well, it is not only about naming but it is also
>> about
>> > > code
>> > > > > > > > > > > > organization. Ivan D. already referenced to
>> alternative
>> > > API
>> > > > > > > styles
>> > > > > > > > (I
>> > > > > > > > > > > > suppose [1] describes the idea).
>> > > > > > > > > > > >
>> > > > > > > > > > > > My main points are:
>> > > > > > > > > > > > 1. Ignite 3 is a great opportunity to make things
>> > better.
>> > > > > > > > > > > > 2. Using (or reusing) confusing names and entities
>> > should
>> > > > be
>> > > > > > > > avoided.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Another rather straightforward startup/bootstrap
>> > approach
>> > > > is
>> > > > > > used
>> > > > > > > > in
>> > > > > > > > > > > > Netty [2]. For Ignite I would spell it like
>> > > > > > > IgniteServer.Bootstrap
>> > > > > > > > > and
>> > > > > > > > > > > > IgniteClient.Bootstrap.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Also I suppose that thin client API is more
>> > > > > > > > > > > > important
>> > > > because
>> > > > > > > much
>> > > > > > > > > > > > more users will use it. I hope that a lot of
>> Community
>> > > > > members
>> > > > > > > will
>> > > > > > > > > > > > share their ideas.
>> > > > > > > > > > > >
>> > > > > > > > > > > > [1] https://www.baeldung.com/java-redis-lettuce
>> > > > > > > > > > > > [2]
>> > > > > > > >
>> > https://netty.io/4.0/api/io/netty/bootstrap/ServerBootstrap.html
>> > > > > > > > > > > >
>> > > > > > > > > > > > 2021-07-09 1:41 GMT+03:00, Valentin Kulichenko <
>> > > > > > > > > > > > valentin.kuliche...@gmail.com>:
>> > > > > > > > > > > > > Ivan,
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I've seen the link, but I still don't understand
>> what
>> > > > > exactly
>> > > > > > > you
>> > > > > > > > > > > propose
>> > > > > > > > > > > > > to change in the current API, and what is your
>> > concern.
>> > > > > Could
>> > > > > > > you
>> > > > > > > > > > > please
>> > > > > > > > > > > > > clarify? How you think Ignite API should look
>> > > > > > > > > > > > > like?
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > -Val
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > On Thu, Jul 8, 2021 at 2:18 PM Ivan Daschinsky <
>> > > > > > > > > ivanda...@gmail.com>
>> > > > > > > > > > > > wrote:
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >> Val, I have already gave examples -- lettuce, a
>> very
>> > > > > > > performant
>> > > > > > > > > and
>> > > > > > > > > > > > >> modern
>> > > > > > > > > > > > >> redis java client
>> > > > > > > > > > > > >>
>> > > > > > > > > > > > >> I can duplicate links again
>> > > > > > > > > > > > >>
>> > > > > > > > > >
>> > > > > >
>> > https://lettuce.io/core/release/api/io/lettuce/core/RedisClient.html
>> > > > > > > > > > > > >>
>> > > > > > > > > > > > >>
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://lettuce.io/core/release/api/io/lettuce/core/api/StatefulRedisConnection.html
>> > > > > > > > > > > > >> https://www.baeldung.com/java-redis-lettuce
>> > > > > > > > > > > > >>
>> > > > > > > > > > > > >> чт, 8 июл. 2021 г., 23:47 Valentin Kulichenko <
>> > > > > > > > > > > > >> valentin.kuliche...@gmail.com
>> > > > > > > > > > > > >> >:
>> > > > > > > > > > > > >>
>> > > > > > > > > > > > >> > Ivan,
>> > > > > > > > > > > > >> >
>> > > > > > > > > > > > >> > Can you please clarify what you mean by
>> "separate
>> > > > > creation
>> > > > > > > of
>> > > > > > > > > > client
>> > > > > > > > > > > > >> > and
>> > > > > > > > > > > > >> > connection"? Can you give an example?
>> > > > > > > > > > > > >> >
>> > > > > > > > > > > > >> > -Val
>> > > > > > > > > > > > >> >
>> > > > > > > > > > > > >> > On Thu, Jul 8, 2021 at 12:53 PM Ivan
>> > > > > > > > > > > > >> > Daschinsky
>> <
>> > > > > > > > > > > ivanda...@gmail.com>
>> > > > > > > > > > > > >> > wrote:
>> > > > > > > > > > > > >> >
>> > > > > > > > > > > > >> > > I'm sorry, but why we didn't consider to
>> > separate
>> > > > > > creation
>> > > > > > > > of
>> > > > > > > > > > > Client
>> > > > > > > > > > > > >> and
>> > > > > > > > > > > > >> > > connection? Why not to make async variant of
>> > > > > connection?
>> > > > > > > See
>> > > > > > > > > for
>> > > > > > > > > > > > >> example
>> > > > > > > > > > > > >> > > [1]
>> > > > > > > > > > > > >> > > [1] ---
>> > > > > https://lettuce.io/core/release/api/index.html
>> > > > > > > > > > > > >> > >
>> > > > > > > > > > > > >> > >
>> > > > > > > > > > > > >> > > чт, 8 июл. 2021 г., 09:50 Pavel Tupitsyn <
>> > > > > > > > > ptupit...@apache.org
>> > > > > > > > > > >:
>> > > > > > > > > > > > >> > >
>> > > > > > > > > > > > >> > > > Val,
>> > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > >> > > > So the plan is:
>> > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > >> > > > - Remove Ignition#start from the public
>> > > > > > > > > > > > >> > > > API
>> > > > > > > > > > > > >> > > > - Make Ignition a class, not an interface
>> > > > > > > > > > > > >> > > > - Add static Ignition#startClient
>> > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > >> > > > Sounds good?
>> > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > >> > > > On Thu, Jul 8, 2021 at 6:13 AM Valentin
>> > > > Kulichenko <
>> > > > > > > > > > > > >> > > > valentin.kuliche...@gmail.com> wrote:
>> > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > >> > > > > Hi Ivan,
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > > > Ignition IS the entry point to Ignite,
>> > > > > > > > > > > > >> > > > > so
>> > I'm
>> > > > not
>> > > > > > > sure I
>> > > > > > > > > got
>> > > > > > > > > > > > your
>> > > > > > > > > > > > >> > point
>> > > > > > > > > > > > >> > > > :)
>> > > > > > > > > > > > >> > > > > Where is the contradiction?
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > > > Either way, please feel free to give
>> > > > > > > > > > > > >> > > > > your
>> > > > > > suggestions
>> > > > > > > > for
>> > > > > > > > > an
>> > > > > > > > > > > > >> > > alternative
>> > > > > > > > > > > > >> > > > > name if you have any.
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > > > -Val
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > > > On Wed, Jul 7, 2021 at 7:56 PM Ivan
>> > > Pavlukhina <
>> > > > > > > > > > > > >> vololo...@gmail.com>
>> > > > > > > > > > > > >> > > > > wrote:
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > > > > A side note. Actually “Ignition”
>> > > > > > > > > > > > >> > > > > > naming
>> > > always
>> > > > > > > > confused
>> > > > > > > > > > me.
>> > > > > > > > > > > I
>> > > > > > > > > > > > >> think
>> > > > > > > > > > > > >> > > > about
>> > > > > > > > > > > > >> > > > > > it as some fancy named API entry point
>> for
>> > > > > Ignite.
>> > > > > > > > > Perhaps
>> > > > > > > > > > > it
>> > > > > > > > > > > > >> > > > > > is
>> > > > > > > > > > > > >> a
>> > > > > > > > > > > > >> > > good
>> > > > > > > > > > > > >> > > > > > moment to revisit naming.
>> > > > > > > > > > > > >> > > > > >
>> > > > > > > > > > > > >> > > > > > > On 8 Jul 2021, at 07:09, Valentin
>> > > > Kulichenko <
>> > > > > > > > > > > > >> > > > > > valentin.kuliche...@gmail.com> wrote:
>> > > > > > > > > > > > >> > > > > > >
>> > > > > > > > > > > > >> > > > > > > Hi Pavel,
>> > > > > > > > > > > > >> > > > > > >
>> > > > > > > > > > > > >> > > > > > > I don't think we will need the pure
>> > > embedded
>> > > > > > mode,
>> > > > > > > > but
>> > > > > > > > > > we
>> > > > > > > > > > > > >> > > > > > > still
>> > > > > > > > > > > > >> > > need
>> > > > > > > > > > > > >> > > > to
>> > > > > > > > > > > > >> > > > > > be
>> > > > > > > > > > > > >> > > > > > > able to access the API from compute
>> and
>> > > > > > services.
>> > > > > > > > That
>> > > > > > > > > > > said,
>> > > > > > > > > > > > >> > there
>> > > > > > > > > > > > >> > > > are
>> > > > > > > > > > > > >> > > > > > two
>> > > > > > > > > > > > >> > > > > > > usages of the 'Ignite' API:
>> > > > > > > > > > > > >> > > > > > >
>> > > > > > > > > > > > >> > > > > > > 1. Remote, via the binary
>> > > > > > > > > > > > >> > > > > > > protocol.
>> > > > > > > > > > > > >> > > > > > > 2. Local - needed for compute and
>> > > > services.
>> > > > > > > (This
>> > > > > > > > is
>> > > > > > > > > > how
>> > > > > > > > > > > > it
>> > > > > > > > > > > > >> > works
>> > > > > > > > > > > > >> > > > > now.)
>> > > > > > > > > > > > >> > > > > > >
>> > > > > > > > > > > > >> > > > > > > I believe that the API should be the
>> > same,
>> > > > and
>> > > > > > > there
>> > > > > > > > > > > should
>> > > > > > > > > > > > >> > > > > > > be
>> > > > > > > > > > > > >> a
>> > > > > > > > > > > > >> > > > > unified
>> > > > > > > > > > > > >> > > > > > > access point. Ignition seems to be a
>> > good
>> > > > > > > candidate
>> > > > > > > > > for
>> > > > > > > > > > > > this.
>> > > > > > > > > > > > >> > > > > > >
>> > > > > > > > > > > > >> > > > > > > Ignition#start should eventually be
>> > > removed
>> > > > > from
>> > > > > > > the
>> > > > > > > > > > > public
>> > > > > > > > > > > > >> API.
>> > > > > > > > > > > > >> > It
>> > > > > > > > > > > > >> > > > is
>> > > > > > > > > > > > >> > > > > > > currently there only because we
>> > > > > > > > > > > > >> > > > > > > don't
>> > have
>> > > > the
>> > > > > > > thin
>> > > > > > > > > > client
>> > > > > > > > > > > > >> > > > > > > yet.
>> > > > > > > > > > > > >> > > > > > >
>> > > > > > > > > > > > >> > > > > > > -Val
>> > > > > > > > > > > > >> > > > > > >
>> > > > > > > > > > > > >> > > > > > >> On Wed, Jul 7, 2021 at 5:47 AM
>> > > > > > > > > > > > >> > > > > > >> Pavel
>> > > > > Tupitsyn <
>> > > > > > > > > > > > >> > > ptupit...@apache.org
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > > > > wrote:
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > > >> Igniters,
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > > >> I have a few questions regarding
>> server
>> > > > node
>> > > > > > > > startup
>> > > > > > > > > > and
>> > > > > > > > > > > > >> > > > > > >> thin
>> > > > > > > > > > > > >> > > > clients.
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > > >> State of things:
>> > > > > > > > > > > > >> > > > > > >> - Server nodes will be started with
>> > > 'ignite
>> > > > > > run'
>> > > > > > > > from
>> > > > > > > > > > CLI
>> > > > > > > > > > > > >> > > > > > >> [1]
>> > > > > > > > > > > > >> > > > > > >> - ignite-api module represents our
>> > public
>> > > > API
>> > > > > > > > > > > > >> > > > > > >> - ignite-api has Ignition interface
>> to
>> > > > start
>> > > > > > > server
>> > > > > > > > > > nodes
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > > >> Questions:
>> > > > > > > > > > > > >> > > > > > >> - What's the idea behind Ignition
>> > > interface
>> > > > > in
>> > > > > > > the
>> > > > > > > > > > public
>> > > > > > > > > > > > >> > > > > > >> API?
>> > > > > > > > > > > > >> > Are
>> > > > > > > > > > > > >> > > > we
>> > > > > > > > > > > > >> > > > > > going
>> > > > > > > > > > > > >> > > > > > >> to have an "embedded mode" where
>> > servers
>> > > > can
>> > > > > be
>> > > > > > > > > started
>> > > > > > > > > > > > from
>> > > > > > > > > > > > >> > > code? I
>> > > > > > > > > > > > >> > > > > > >> thought this was not planned.
>> > > > > > > > > > > > >> > > > > > >> - How are users supposed to
>> > > > > > > > > > > > >> > > > > > >> retrieve
>> an
>> > > > > > instance
>> > > > > > > of
>> > > > > > > > > the
>> > > > > > > > > > > > >> Ignition
>> > > > > > > > > > > > >> > > > > > interface?
>> > > > > > > > > > > > >> > > > > > >> - Are there any plans to start thin
>> > > clients
>> > > > > > from
>> > > > > > > > > > Ignition
>> > > > > > > > > > > > >> > > interface,
>> > > > > > > > > > > > >> > > > > or
>> > > > > > > > > > > > >> > > > > > >> should we have a separate way of
>> doing
>> > > > this?
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > > >> [1]
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > >
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > >> > >
>> > > > > > > > > > > > >> >
>> > > > > > > > > > > > >>
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158873958
>> > > > > > > > > > > > >> > > > > > >>
>> > > > > > > > > > > > >> > > > > >
>> > > > > > > > > > > > >> > > > >
>> > > > > > > > > > > > >> > > >
>> > > > > > > > > > > > >> > >
>> > > > > > > > > > > > >> >
>> > > > > > > > > > > > >>
>> > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > --
>> > > > > > > > > > > >
>> > > > > > > > > > > > Best regards,
>> > > > > > > > > > > > Ivan Pavlukhin
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
--
Best regards,
Ivan Pavlukhin
