> But configuration should be a POJO - a class with setters and getters, nothing else. Why it should? Why ClientConfiguration should be serializable? Who needs that? Xml configuration even in spring are not widely used for years :)
вс, 11 июл. 2021 г., 00:57 Pavel Tupitsyn <ptupit...@apache.org>: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >