Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Reply-To: niclas@hedhman.org
In-Reply-To: <CAGxfHu=7M0Aiqx4+cLna0OEDSQCo-z=hh688aeSFw+43DcxCiA@mail.gmail.com>
References: <CADmm+Ked=5T-WoFiMp3Agv62kq7fOomGYUO6OCSz67_ZjMnhew@mail.gmail.com>
 <CADmm+Kcoi_DKqn9ZHNxgj_TdvwhsKRjS7Qob6D6Fw8J9pBH5Gw@mail.gmail.com>
 <CADmm+Ke4LpNiwTMPW5==9N2yxcQ35Beto5ggmgkjSd4YFCaARg@mail.gmail.com>
 <CADmm+Kc01XRdEZSqAyRARhdkbJJh4rLxSExqS18y+8RrUkCK2g@mail.gmail.com>
 <CADmm+Kcf7g2OPmf0F9nB8A70rcZV9KVmdEibrTyt-5bNhG0qQg@mail.gmail.com>
 <CADmm+KezPv5NHaPTVCfAPcZQ3PkpBBKN-Q4mjemYYkGFVu6UOg@mail.gmail.com>
 <CADmm+Kd2=G_C0H01GFTYuLdEmmGFWB1LfYh-Eyi+73vyMqZ3uw@mail.gmail.com>
 <CADmm+KfD6vOcxUaWSBeNq8oU7E4XGHh-Q3SSYBRidUSdYn0p8g@mail.gmail.com> <CAGxfHu=7M0Aiqx4+cLna0OEDSQCo-z=hh688aeSFw+43DcxCiA@mail.gmail.com>
From: Niclas Hedhman <hedhman@gmail.com>
Date: Tue, 23 Aug 2016 07:55:21 +0800
Message-ID: <CADmm+Kcqw978eVmyJEoK6vd16r205a388rh14pUahkkpXq=SPA@mail.gmail.com>
Subject: Re: Spring
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c192a3601ee99053ab1c809
archived-at: Mon, 22 Aug 2016 23:55:28 -0000

--94eb2c192a3601ee99053ab1c809
Content-Type: text/plain; charset=UTF-8

Nemeth,
Welcome to the world of Zest.

There is a lot of goodies in your mail, and I agree with a lot of what you
said.

As for Configuration, what Zest provides out if the box is;

1. Configuration is an Entity that can be stored, and modified in runtime.

2. If no Entity is found in the Entity Store (for config), it tries to
create one from a properties file (your sensible defaults).

3. Services are expected to do refresh() on the Configuration composite,
which will reload.

4. Since implementing an entity store is relatively easy, we are only
lacking particular implementations.

Finally, there is no "chaining" of stores, which could be used for override
mechanism. So, relatively little effort is needed in your first item. :-)

For auto-configure, I am not sure what you are trying to say. Perhaps you
are only expressing a need that is more or less already fulfilled with the
ConfigurationComposite functionality in Zest.

But at "clouding tools" I think you are bringing up new functionality in
Core....

Currently, the @Service fulfilment is done inside the Zest Core, but
perhaps that should be broken out as an SPI (even for the current default).
If we follow the normal way to define an SPI, it would simply be a Service
that implements something like ServiceProvider interface, but then the
question is, how is that service being provided for, so a bit of
chicken-egg problem, but probably doable with a fallback implementation.

The services abstraction already support another highly needed feature in
remote service scenarios, Availability. What we should add for that is
CAP-theorem declaration, which would match the need of the client with the
capability of the service.

And finally, "asynchronous" is a big thing in modern systems, so perhaps a
new type of abstraction is needed for asynchronous request/response pattern
of services. That is probably a large new feature that should be discussed
separately...

Cheers
Niclas

On Aug 22, 2016 15:26, "Nemeth Sandor" <sandor.nemeth.1986@gmail.com> wrote:

> Hello Niclas,
>
> I would say that Zest do not fit into the Spring world, I think the
> conceptual gap between the two worlds are way too big. I mean Zest doesn't
> support e.g. POJOs, also provides a different dependency-injection method.
> One could probably force a Spring+Zest combination to work, but it would
> never be a perfect match.
>
> However from my POV it should be possible for Zest to offer the same
> convenience-level, along with the tooling support.
> This would have 3 different aspects:
>
> 1) configuration management
> 2) auto-configuration support
> 3) Cloud tooling
>
> Below a description follows, although I am not _that_ familiar with the
> Zest internals at the moment, so please correct me if I am wrong at any
> point.
>
> The *configuration management* would include providing a concept of
> configuration override with an ordering, supporting external key-value
> stores for loading configuration (with reload support). I would propose the
> following order:
>
> - External K/V store (etcd, Consul, Spring Cloud Config Server, etc)
> - Environment variables
> - External configuration files (outside of the application)
> - Internal configuration files (packaged with the application)
>
> The *auto-configuration* support is a bit tricky from my perspective,
> because usually one wants to provide default settings which make sense, but
> provide an override capability. I could imagine having something like an
> _AutoConfiguringApplicationAssembler_ which auto-discovers and assembles
> an
> application (using Java SPI) but then the user could override it in the
> _assemble_ method.
>
> For the *cloud tooling* Zest could provide a unified service-discovery
> support for different service-discovery providers, and then provide support
> for different service discovery and load-balancing methods (e.g client-side
> load balancing or 3rd party API gateway).
>
> Best regards,
> Sandor
>
> On Wed, 17 Aug 2016 at 03:01 Niclas Hedhman <niclas@hedhman.org> wrote:
>
> > Those who know me well, are well-aware of my generally negative opinion
> > about Spring framework, as it has created more mess in software than what
> > is reasonable for such a framework.
> >
> > BUT, I am not stuck about it, and I want to highlight something that
> looks
> > really, really cool.... http://start.spring.io
> >
> > Also take a look at a frantic presentation by Josh Long about it;
> > https://www.youtube.com/watch?v=sOP3x6ODQWQ
> >
> > With that in your minds, How does Zest fit into that world?
> >
> > Cheers
> > Niclas
> >
>

--94eb2c192a3601ee99053ab1c809--