Remove configuration by file

[jvermillard]

Cf, as a first-class java library, should not come with a file-based configuration framework but should expose a Java API to configure lt like other Java libraries.

Reasoning:
when you build an application with Cf you consume many other Java libraries. Hopefully, they all do not save files on your disk by default!

You have many components to configure in an application and 20 different ways to do it ( env vars, cmd line args, file (ini, toml,yml, json).

We should simplify not enforce one in Califonium by removing the file facilities and just keeping the Java API to for the end user to configure it.

[boaks]

Maybe you start reading the discussions, when the new Configuration was introduced with 3.0.
It's a question, who is considered to be the "end user".

Anyway, I guess, when #2142 is solved, you will be able to use this library and provide what ever format you want on your application level. Maybe we need to adapt the API, if you find a show stopper. Or we need some fixes. But in general, I think this is a really good solution, which provides an easy way to configure a Californium application by a documented configuration file.

[boaks]

If you want to implement a own reader, we can also expose the Definitions<DocumentedDefinition<?>> definitions; to enable to use this definitions. That should make it possible to implement a generic json or yml reader.

[jvermillard]

I want my CoAP library to refrain from embedding config file reading facilities, imagine if the 20 lib I use had the bad taste to do this.
I use whatever I want to configure my app and call Java functions.

For example how another Java CoAP library is doing:

// build CoapClient that connects to coap server which is running on port 5683
CoapClient client = CoapServer.builder()
        // define transport, plain text UDP listening on random port
        .transport(udp())
        // (optional) define maximum block size
        .blockSize(BlockSize.S_1024)
        // (optional) set maximum response timeout, default for every request
        .responseTimeout(Duration.ofMinutes(2))
        // (optional) set maximum allowed resource size
        .maxIncomingBlockTransferSize(1000_0000)
        // (optional) set extra filters (interceptors) to outbound pipeline
        .outboundFilter(
                // each request will be set with different Token
                TokenGeneratorFilter.sequential(1)
        )
        // build client with target server address
        .buildClient(new InetSocketAddress("localhost", 5683));

This doesn't have the bad idea to ask you to look at a two-level generic abstract concept like Definitions<DocumentedDefinition<?>> definitions to provide a couple of config values to the lib.

Or this HTTP Java lib:

OkHttpClient client = new OkHttpClient.Builder()
      .readTimeout(1, TimeUnit.SECONDS)
      .build();

Or in a Go CoAP library:
you provide a configuration struct to the CoAP server/client initialization function

	dtlsCfg := &piondtls.Config{
		PSK: func(hint []byte) ([]byte, error) {
			fmt.Printf("Hint: %s \n", hint)
			return []byte{0xAB, 0xC1, 0x23}, nil
		},
		PSKIdentityHint: []byte("Pion DTLS Server"),
		CipherSuites:    []piondtls.CipherSuiteID{piondtls.TLS_PSK_WITH_AES_128_CCM_8},
	}
	conn, err := dtls.Dial("pluggedin.cloud:5684", dtlsCfg)

Or in libcoap C: https://github.com/obgm/libcoap-minimal/blob/main/client.cc#L39-L40

Here Californium has an unorthodox design for configuration, breaking the UX principle of least astonishment and making the library difficult to use:
you need to skim configuration.java, and understand what Cf means for modules and other providers.
When in the end, what you want is the default config, configure what you need for your application, like any libs.
I had never seen someone managing to get Californium configuration right the first time, and I've been working in this CoAP field for quite a long time now.

[boaks]

		CoapConfig.register();
		Configuration configuration = Configuration.createStandardWithoutFile();

		configuration.set(CoapConfig.PREFERRED_BLOCK_SIZE, 1_024)
					.set(CoapConfig.EXCHANGE_LIFETIME, 2, TimeUnit.MINUTES)
					.set(CoapConfig.MAX_RESOURCE_BODY_SIZE, 1_000_000);

[boaks]

As I wrote, you don't need to use the properties file.

[boaks]

I had never seen someone managing to get Californium configuration right the first time,

What was required to be changed in the default configuration?

and I've been working in this CoAP field for quite a long time now.

That new Configuration is for sure not in use for that "quite a long time", so it seem that the trouble must have other roots ;-).

[jvermillard]

What was required to be changed in the default configuration?

Blocksize to 1k max resource body, DTLS cipher suites, disabling CID, DTLS role.

That new Configuration is for sure not in use for that "quite a long time", so it seem that the trouble must have other roots ;-).

Seriously Achim, if your idea was to make fun of me, I don't think it's appropriate behavior. The file-based configuration predates us.

[boaks]

For me, your statements are superficial and don't reflect the experience you have.
I'm not sure, what you want to achieve. I guess, this "issue" will be the wrong way.

I answered your question, you can use Californium without properties file.
You can configure all the values you mentioned above, quite straightforward.

I can't see, that this a question of "file or no file".

Others, including me, enjoy using this possibility of a general configuration file. This enables people to build small tools (e.g. cf-simplefile-server ) and very easy make their experience with different configuration values.

If you really want to "change" Californium, please consider to ask Matthias and Kai as well. I don't stick to maintaining this stuff. If you want to start over with 5.0 (I will keep the 4.0 in coexistence for smaller API cleanup), then I don't see, what should prevent you from doing so.

[boaks]

If you want to lead a "start over", let me know.