Ivan D,
Let's compare WebClient approach with Ignite 2.x approach:
// Ignite 2.x
var cfg = new ClientConfiguration()
.setAddresses("127.0.0.1:10800", "127.0.0.1:10801")
.setTimeout(4000);
Ignite client = Ignition.startClient(cfg);
// Ignite 3.x inspired by WebClient
Ignite client = IgniteClient.builder()
.setAddresses("127.0.0.1:10800", "127.0.0.1:10801")
.setTimeout(4000)
.build();
To me, there is virtually no difference. Both are simple and
straightforward.
"specific static method within strange class with strange name" (whatever
that means) can be applied equally to both.
However, ClientConfiguration is a POJO with all the corresponding benefits,
like easy serialization.
WebClient.Builder is an interface that does not even provide a way to get
the property value back.
To be clear, I don't have strong opinions on naming (it can be
Ignition.start or IgniteClient.connect or whatever).
But configuration should be a POJO - a class with setters and getters,
nothing else.
On Sat, Jul 10, 2021 at 9:49 PM Ivan Daschinsky <ivanda...@gmail.com> wrote:
> Pavel, I and Ivan P. have already get examples of lettuce.io
>
> Another example is spring 5 reactive WebClient
> https://www.baeldung.com/spring-5-webclient
>
> сб, 10 июл. 2021 г., 19:50 Pavel Tupitsyn <ptupit...@apache.org>:
>
> > Ivan D.,
> >
> > > simple and straightforward client builder
> > Can you please provide an example of that, a piece of code with suggested
> > API usage? Ideally compared to the current 2.x approach.
> >
> > On Sat, Jul 10, 2021 at 3:20 PM Ivan Daschinsky <ivanda...@gmail.com>
> > wrote:
> >
> > > It is a quite questionable decision , as for me, to have specific
> static
> > > method within strange class with strange name (and it is a well known
> > > antipatter ) with chained twisted configuration class instead of just
> > > simple and straightforward client builder, isn't it? Name 'Ignition' is
> > may
> > > be fun, but I cannot understand how it name connects to bootstraping
> > > ignite's client.
> > >
> > > сб, 10 июл. 2021 г., 14:17 Pavel Tupitsyn <ptupit...@apache.org>:
> > >
> > > > 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
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
