Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <559469C2.4010307@gmail.com>
References: <5592F85E.6050907@zest.mail.kapsi.fi>
 <CADmm+Kd7K_qUAw6jfjW3qucAooTSDsr9aGEEUDsxX6kdw3dOig@mail.gmail.com>
 <5594368C.6010909@zest.mail.kapsi.fi> <559469C2.4010307@gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Thu, 2 Jul 2015 08:39:39 +0200
Message-ID: 
 <CADmm+KcyS=+ZLcvZx592xpyNDmqsQui=f+VziC95q7+MM4eegQ@mail.gmail.com>
Subject: Re: Qi4CS and Zest
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=047d7bd757585476f40519deb5ff

--047d7bd757585476f40519deb5ff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Long time ago I suggested something like this;

   Entity =3D Identity + Meta + Value

where Identity and Meta are Immutable and the Value can only change
atomically.

And then TimeseriesEntity, which stores a timestamped sequence of Values.
(This can't really be modeled effectively at the moment, since one can't
leverage the timeseries support built into Cassandra and possibly other
stores.)


All these "advanced usecases" points towards what Kent is hinting; A major
design overhaul.

Speaking from experience; When the previous major overhauls took place, I
and Rickard basically spent hours on the whiteboard trying to figure out
how it was going to work. It was tiresome and painful, discussion mixed
with coding, and most importantly Rickard's ability to crank out working
code in no-time, something now not available.

Soooo, to avoid taking more water over our heads than can be handled, I
think a couple of smaller experiments will be needed;
  a. Find out whether UnitOfWork can be divorced from.
  b. Find out whether Module can become a Composite and customizable.
  c. Find 10 people willing to do the work. ;-)


Exciting, yes. Scary, yes...


Niclas

On Thu, Jul 2, 2015 at 12:29 AM, Kent S=C3=B8lvsten <kent.soelvsten@gmail.c=
om>
wrote:

> Wow!
>
> A lot of interesting food for thought going on recently!
>
> A short while ago Niclas began thinking about messaging - And
> introducing MessageComposites with as yet unspecified behaviour.
> Something seemed wrong - but I was unable to fingerpoint it .... But
> somehow introducing a new composite type seemed wrong.
> Each composite type seems to require us a lot of additions to the core -
> new interfaces/builders/methods on module/assembly - new fields and
> constructor arguments in the instances.
>
> We shortly discussed some UOW stuff - seems like a MessageComposite has
> something entity-like - on the other hand the raw message should be
> immutable, so it is sort of a ValueComposite too.
> It might be durable - which would probably require some persisting of
> it's value coupled with some "metadata" (probably common to all
> messages) - so more Entity similarities.
>
> It could be cool to register a message, using some sort of SPI to handle
> the sending - but using the normal EntityStore to handle persistence
> sonehow - that would fit nicely with letting the message handling be a
> side effect of apply()'ing the UOW.
>
> Could it be possible to handle messages as something built upon entities
> and values - and adding some new stuff - and also magically adding the
> required persistent properties behind-the-scene containing required meta
> data (what is this message, when was it created, to which UOW does it
> belong, has it been sent?) something like that.
>
> That would require us adding a new feature to the core. Currently we
> only add implementations to statically declared methods/properties - but
> could we introduce adding new undeclared properties to a "Message
> composite". It might not be a good idea to allow application code to add
> properties or methods - but allowing the core itself to add properties
> (possibly private as in 'private mixin') - that might not be too bad?
>
> Somehow implement message support as some sort of "plugin" building upon
> existing functionality - under the hood converting creation of a message
> composite to an entity/value pair with some persistence and a
> service/SPI to handle sending the message - maybe a concern to handling
> storage on completion of a UOW.
>
> Another post that caused my head to start spin a bit was Niclas
> discussing entity lifecycle design flaw - and the possibility of using a
> concern there for lifecycle handling - on EntityBuilder#newInstance and
> UOQ#complete() ... this possibility to add stuff on creation/destruction
> is something we already have on services - in the form of
> activate/passivate. Well, both entities and services are composites ...
> could a UOW be a composite too? Speaking of similarities .... A service
> has no state - on the other hand the configuration of a service could in
> some way be regarded as (hidden) properties on the service
>
> And now Stanislav explaining Qi4CS ... no entities ... small core ...
> with "complicated extensions" for handling additional composite types -
> not too far from the message composite thought vaguely described above.
>
> I really like this idea! ... well ... sort of.  One of the ideas of Qi4J
> I found attractive was leaning on the DDD concepts - services, entities,
> values. This should be kept for application writers - but we might be
> able to use the idea internally in the core without exposing the fact -
> maybe, just maybe we could implement value handling as an immutability
> concern on top of a plain composite? Maybe, just maybe we could
> implement entity handling as some services/concerns/mixins on top of a
> PlainComposite (I like that name, too!) - But still keep the types
> explicit in the API/assembly (allowing for ading new types).
>
> Next thought: We really want some of the composite types to be explicit
> for application writers - but it would be nice to allow adding new
> composite types (messages). Hmmmm, could a Module be some sort of
> (structural/architectural) Composite, too? Composes of some
> entity-handling/value-handling/service-handling. Obviously that could
> lead to some chicken and egg problem (or "It's turtles all the way
> down"). But would represent an awesome fit with the vision of Qi4J as
> "composite-oriented programming" - hmmmm could we consider services as
> properties on a module ?
>
> Maybe adding new features to a basic ModuleComposite is really what we
> need for a proper handling of spatial extensions too?
>
> A lot of hairy stuff to digest - no clear thoughts as yet - but still
> interesting... I think.
>
> /Kent
>
>
> Den 01-07-2015 kl. 20:50 skrev Stanislav Muhametsin:
> > Hi Niclas,
> >
> > Thanks for comments!
> > My replies are interweaved below.
> >
> > On 1.7.2015 16:40, Niclas Hedhman wrote:
> >> A few comments now;
> >>    Meta-Info and Uses --> No, they are not really the same. The
> >> former is
> >> about providing information to the "Type" but the latter is to
> >> provide to
> >> the "Instance". I wouldn't want to merge those.
> >
> > Hmm, well they are both serving same purpose, just on different levels
> > ("type" vs "instance").
> > In Qi4CS, the CompositeAssemblyDeclaration in Assembling layer, the
> > CompositeModel in Model layer, and CompositeBuilder in Instance level
> > all implement interface which lets you specify values for [Uses]
> > injection.
> > When the injection value is provided, the Qi4CS first looks up for
> > suitable value first in Instance layer, then Model layer, and finally
> > Assembling layer.
> > This way you can specify the values for "Type" on Assembling level,
> > but at run-time, you can override those values (if needed) through
> > e.g. CompositeBuilder.
> >
> > For me personally, that has worked like a charm.
> > You may have noticed that I've taken same stance on this issue as with
> > the @Mixins -> [DefaultMixins] issue: letting the end-user always
> > override whatever "default" implementation there is.
> > If there will be need to pass data strictly on "Type" level (this
> > would mean Assembling and Model layers I think), that can always be
> > added.
> >
> >> Architecture --> There is a concept that might need to be explored
> >> further.
> >> In Zest, the Architecture is implicit from the Layer#uses() and other
> >> calls. Perhaps it should be a more explicit concept.
> >
> > I will be happy to discuss this topic when you will have time and
> > energy to explore it. :)
> >
> >> C# properties --> I don't know whether that good enough or not. I gues=
s
> >> meta-info isn't of interest, and I assume that there is a way to make
> >> them
> >> read-only. Also, since LiNQ can leverage it, I guess there is a
> >> reasonable
> >> amount of sophistication, and don't need to elaborate on it.
> >
> > IIRC Zest Property<T> type also exposes always both setter and getter,
> > right?
> > To make one immutable, one applies @Immutable annotation.
> > In Qi4CS, that is done in similar way, you apply [Immutable] attribute
> > on a property to make it immutable (once prototype has been
> > instantiated).
> > Both getter and setter must be present though, in order to be able to
> > set the property in a type-safe way during prototype stage.
> >
> >> Complex Extensions --> A huge topic, whether it would be possible to
> >> make
> >> Storage/Indexing/UoW/EntityComposite as extension to Core. Sounds
> >> close to
> >> impossible, considering the handling needed. But perhaps a spike on th=
e
> >> topic would be worth it...
> >
> > Ah yes, the work to implement this in Zest would be probably quite
> > huge, since it wasn't designed like that in the beginning.
> > It was hard, yes, but both Plain Composites and Service Composites in
> > Qi4CS are implemented using the mechanisms that the Qi4CS Core
> > provides for implementing any composite type.
> > So the mechanisms are already in use there and all stuff specific to
> > certain composite type is decoupled from rest of the Core.
> > Obviously, if I would start to implement Entity Composite in Qi4CS as
> > an Extension, I would most likely run into some problems and would
> > need some small modifications into the types that the mechanisms
> > consist of.
> > But I don't think there would be anything really serious about it,
> > just a lot of work.
> >
> >> Application's Name/Version/Mode --> Is still in Zest.
> >
> > Great, then Qi4CS isn't outdated in that manner. :)
> >
> >> Correction --> Layers can't hold composites in Zest. Those methods are
> >> "selectors" of the composites that are inside modules of the Layer, a
> >> bit
> >> like JQuery.
> >
> > Ahh, okay, good to know!
> >
> >> Annotations for lifecycle methods --> yeah, I remember I suggested
> >> that a
> >> long time ago, but one of the problems is another item that you don't
> >> touch
> >> on, which also may be implemented differently; namely; Zest will ONLY
> >> take
> >> the methods from the declared Mixins that are needed. So if one
> >> declares a
> >> Mixin that implements Lifecycle, without Lifecycle being part of the
> >> Composite's type, then those are effectively ignored. Does Qi4CS
> >> "glue on"
> >> all Mixins that are declared??
> >
> > Qi4CS doesn't "glue on" mixins (I actually remember this discussion
> > about glueing and cherry-picking mixins in old Qi4j mail list).
> > So it behaves in same manner as Zest then: it will ignore any methods
> > that are not part of the composite types declared at assembling stage.
> >
> > However, it does detect during creation of Composite Model if a mixin
> > has "special" methods (the ones marked with the
> > Prototype/Activation/Deactivation attributes), and those will then be
> > modeled as Special Method Models.
> > So you can have a mixin not implementing *any* of the composite types,
> > and just having "special" methods, and as long as you have included
> > this mixin in composite assembly declaration, these methods will be
> > picked up by Qi4CS.
> >
> >> That said, Paul's "@Activators" construct changes this a bit, I
> >> think, as
> >> those are handled explicitly, but that is only for services.
> >
> > Hmm, I tried to search for "Activator" but I only got commit mails.
> > Is it an annotation which specifies types which implement Activatable
> > interface so that Zest would pick them up?
> >
> >> Stan, thanks for the run through, and it gives enough food for thought=
.
> >
> > Glad the mail was of use! :)
> >
> > P.S. When reading my original mail after sending it, I noticed I
> > forgot to mention that Configuration Composites are implemented as an
> > Extension in Qi4CS.
> > They are not a new composite types by themselves, but they provide
> > ways to read/save other composites, which are the composites which
> > hold actual configuration data.
>
>


--=20
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--047d7bd757585476f40519deb5ff--