Redesign configuration.

[boaks]

WIP

First results of the configuration redesign.
See issue #1648

Signed-off-by: Achim Kraus achim.kraus@bosch.io

[sbernard31]

Maybe I missed something but it seems this doesn't compile ?

[ERROR] /home/sbernard/git/californium/element-connector/src/test/java/org/eclipse/californium/elements/rule/NetworkRule.java:[31,47] cannot find symbol
  symbol:   class UdpConfig
  location: package org.eclipse.californium.elements.config
[ERROR] /home/sbernard/git/californium/element-connector/src/test/java/org/eclipse/californium/elements/rule/NetworkRule.java:[524,28] cannot find symbol
  symbol:   variable UdpConfig
  location: class org.eclipse.californium.elements.rule.NetworkRule
[ERROR] /home/sbernard/git/californium/element-connector/src/test/java/org/eclipse/californium/elements/rule/NetworkRule.java:[525,28] cannot find symbol
  symbol:   variable UdpConfig
  location: class org.eclipse.californium.elements.rule.NetworkRule

Missing UdpConfig class ?

[boaks]

Yep.

I currently work on split the config values and adapt the Connector constructors to use Configuration, sometimes with additional parameters, see the new Tcp- and TlsClientConnector. There is still so much to type ...

[sbernard31]

(with last push --force, It compiles now)

[sbernard31]

I looked at this. (Not so deeply)

And I think it is clearly better 👍
We have a better separation of concern and discover API with autocomplete would be probably easier (with to Definition + typed setter/getter in Configuration)

I'm not sure if this will replace existing Builder or if we will still have both config + builder ?
I refer to my previous comment :

d1) NetworkConfig is about everything ? udp, dtls, coap, tls, http, tcp but in a same time there is also a DtlsConnectorConfig.Builder or CoapEndpoint.Builder. The responsibility of those classes sounds not so clear. Why some setting are in some builder and other in NetworkConfig? answering to those responsibility/scope questions could maybe help to define the new design.

(source : #1601 (comment))

Currently the only part I'm not so comfortable with is the static Configuration.MODULE field and static blocks which registers module.

Looking at PR, I was thinking that you created a kind of generic Configuration framework (not really linked to Californium or CoAP). I mean it could almost be a separated library. My next thought was : "maybe there is already some library which does this kind of thing ? 🤔 "
Did you look at this or did you consider this ?

[boaks]

I'm not sure if this will replace existing Builder or if we will still have both config + builder ?

The part of simple parameter maybe repaced by the config. the part of interface implementations not. For DTLS I consider to keep the builder but replace the simple settings by the config.

My next thought was : "maybe there is already some library which does this kind of thing ? thinking "
Did you look at this or did you consider this ?

It's inspired by netty.io - AttributeMap.

I considered to switch to yaml, but withdrawn it. I don't like external dependencies for close to nothing.
Especially not, if they are used for the core and/or with Android. The implementation is now basically 1 class and 1 interface, and several simple data-definition classes. The rest is the setup for Californium. And the most work is always to change the available code to use it, regardless what you use.

Just a hint, did you had a look on the created properties files? For me that is also a really large improvement to have it sorted and documented.

[sbernard31]

Just a hint, did you had a look on the created properties files? For me that is also a really large improvement to have it sorted and documented.

I just looked at this : very cleaner ✨ . (maybe default value could be added with description in comment)

Any thought about :

Currently the only part I'm not so comfortable with is the static Configuration.MODULE field and static blocks which registers module.

[boaks]

Currently the only part I'm not so comfortable with is the static Configuration.MODULE field and static blocks which registers module.

Making that more "dynamic" seems to me to be a difficult idea. Especially the use to generate the initial properties file may get irritating.

[sbernard31]

Making that more "dynamic" seems to me to be a difficult idea. Especially the use to generate the initial properties file may get irritating

I understand the concern but the static one as also some drawback, the main one is :
A user could have some params in his files which should not be there (which he don't really need)

e.g : I have 2 config(2 different file), one for coap over tcp and one for udp in same application, I will have udp param in my tcp confg and tcp params in my udp config.

[boaks]

Yes.
But I'm not sure, if two files will not create more maintenance (shared coap-config) then provide benefits.
In some examples I use more files, but that's more about different services not about select protocols.

[sbernard31]

But I'm not sure, if two files will not create more maintenance (shared coap-config) then provide benefits.

It's a case which show that maybe putting everything in the same file is not so good ?

In my experience static design create issues frequently, I try to think if in this particular case we can imagine some realistic use case where this will be an issue. 🤔