Hi there Patrick.
I have not checked the wiki page, but if you have not updated that page
with the proposal then could you possibly do that.
I need to visualize the problem and reading a bunch of words does not
visualize it for me. Visualizing it might actually help describe the
future and extension capability as well.
--Udo
On 4/19/18 17:03, Patrick Rhomberg wrote:
Hello all!
We introduced the CacheElement interface as part of our experimental API
to update the cluster configuration. I'd like to solidify and document our
intent for the interface and the extent to which it is expected to apply.
In its current form, the CacheElement interface extends Serlializable and
Identifiable<String>. Serialization is required for communication between
members, and Identifiable is useful during lookup, modification, and
removal of an existing configuration object.
At our current iteration, it is not entirely clear which of our own
configuration objects should or should not implement CacheElement. I think
one of following interpretations may be best, but don't know which would be
most natural. And, of course, if you have another that I've overlooked,
I'd love to hear it.
Classes that implement CacheElement are...
A) ... only custom configuration elements provided by extension
developers. This declaration will appear at a top-level class declaration
that is directly consumed by the CacheConfig or RegionConfig.
B) ... custom configuration elements, as well as any configuration object
that we wish to be searchable within the configuration.
C) ... custom configuration elements, as well as any configuration object
appearing at the same level in the configuration hierarchy. That is, every
getter of both CacheConfig and RegionConfig should return either a
CacheElement, or a List<CacheElement>.
D) ... any object, excepting those in java.lang.*, that appears anywhere in
the cluster configuration's hierarchy, including all inner classes. For
example, ConnectorService.RegionMapping implements CacheElement.
Each comes with its own potential pitfalls.
Option (A) seems restrictive and sparse.
Option (B) is subjective.
Many classes do not have a `name' or `id' field, making option (D)
difficult.
I like option (C), although we have already moved beyond that
specification in our current iteration, with ConnectorService.RegionMapping
implementing CacheElement.
Thoughts?
Imagination is Change.
~Patrick Rhomberg
