Maintenance mode ?

[jvermillard]

Now that Californium has no corporate sponsors to improve and maintain such a complicated project and communication issues between committers, maybe it's time to move to maintenance mode:

• no new feature
• bug fix release based on the community involvement

I started to work with Californium 3.7 recently, debugging minor issues, and my feeling is that the code is too old, too complex, with an enormous scope (from base CoAP/DTLS lib to k8s clustering), and it's going to be challenging to keep running the project as-it-is without a clear full-time corporate workforce.

[boaks]

In my experience, the range of jobs around Californium is large.

There are small extensions as issue #2124 (PR #2125) and big ones as TCP or DTLS 1.3. The number of such jobs has not been too large. But the big ones requires a lot of effort. If it's possible to split that effort in smaller packages, then that may have a chance, to make iterative progress. As in any project, such small iterations need to balance the steps forward against the things, which gets changed, maybe even broken. In the past (e.g. release 3.0, introduction of DTLS 1.2 CID) I used to keep such work in a separate branch in order to keep the negative influence of such changes small. That requires even more effort, but on the other side, it helps to keep the "main" usable.

From my view, I'm not sure, if an explicit "maintenance mode" without new features is required. At least I'm currently spend some time in my "CoAP-S3-Proxy" idea. That doesn't change to much in the library itself, but hopefully helps to gain more usage and publicity. We will see.

For other tasks/jobs I think, that this takes generally a commitment, if there is enough interest, either within the existing committers or for new committers. If that's missing, then it will not be done. I'm not sure, when we lost the "transparency" at that, especially in the TCP work. But I would not use that as example. For other stuff that have been working better.

[boaks]

I started to work with Californium 3.7 recently, debugging minor issues,

Just if you like, in which part?

and my feeling is that the code is too old, too complex,

Yes, in my experience, to do all the refactoring and redesign in the past years, it would have required much more than one. I usually just focus on smaller parts and try to improve that.

with an enormous scope (from base CoAP/DTLS lib to k8s clustering), and it's going to be challenging to keep running the project as-it-is without a clear full-time corporate workforce.

On the other side, there are not too many issues reported.

[jvermillard]

To clarify my position on Cf and why I don't spend too much time on it:

CoAP-S3-Proxy is precisely where I have an issue and why I lost interest in this project.
When I started to work with the initial team when the project started moving to Eclipse, I began to make Cf a first-class Java library introducing maven for packaging & release the libs, pushing to simplify the structure.
I wanted to eliminate the complex config framework logic with files, element connector and keep Cf as an idiomatic Java library project.

But quickly, I saw that other committers were more willing to keep the config files, and keep the project large in the style of a large Java enterprise project. This kind of project could not be sustainable in the long term and is not my cup of tea. So since I have less time and less budget to invest in Cf, I walked away.

IMO Cf & Sc should be a plain Java library focusing on the CoAP and DTLS implementation and the developer API.
Now in the core Cf code, we have a clustered DTLS connector, the whole config logic, element connector dependency, and other things that differ from what I expect from a CoAP library.

If someone wants to build a CoAP S3 proxy or a clustered implementation, they could do it outside the project and keep the library simple to consume for a newcomer.

What is going to attract Java developers is a clear scope, a thread model that is easy to understand, easiness of getting started, and a friendly Java API.

As you said, it's working well enough and since there are not many alternatives, I feel like just maintaining the code have a lot of value. But it's not going to happen to modernize the code (java 8/17 friendly API) until the project is so big and confusing.

[boaks]

Thanks for to frank feedback.

CoAP-S3-Proxy is precisely where I have an issue and why I lost interest in this project.

The CoAP-S3-Proxy itself or stuff like that?

If someone wants to build a CoAP S3 proxy or a clustered implementation, they could do it outside the project and keep the library simple to consume for a newcomer.

That's possible, at least in parts. Some stuff requires some hooks. And some stuff is part of the demo-apps, so already split off.

[boaks]

What is going to attract Java developers is a clear scope, a thread model that is easy to understand, easiness of getting started, and a friendly Java API.

Sure, and all that requires time.
So is the main point, that you think spending the time in that will better pay off than spending the time in the CoAP-S3-Proxy?

[boaks]

In order to have time for an open discussion, I consider not to merge PR #2074 for the next release.

Without that, the list of current changes is not too large:

• 95531fe 2023-05-10 Amend javadoc of Configuration.
• d7e37c8 2023-05-10 Update repo name in cf-unix-setup to eclipse-californium.
• dcbdf81 2023-05-10 Revert names of interoperability tests to tinydtls-client and -server.
• 261defe 2023-04-04 Add missing MAX_ACK_TIMEOUT to coap-definitions.
• 47e2ddf 2023-03-26 Add set of ARIA cipher suites.
• 8c103bd 2023-03-15 Add function to determine full or abbreviated handshakes.
• 012e857 2023-02-14 Add hint about wrong PSK secret.

anyway, I think, a release 3.9.0 including this changes will be a good next step and doesn't limit this discussion.

Any opinion/feedback on a 3.9.0 release with these changes?

[boaks]

More than half a year without someone shows interest in this.
Do you prefer to keep it? Or could it be closed?

[boaks]

If you feel, this is still important, maybe an exchange in the IoT working group gets a better picture about that approach.
For myself, I don't see the benefit.