search

eclipse-californium / californium

CoAP/DTLS Java Implementation
https://www.eclipse.org/californium/
Other
723 stars 361 forks source link

Maintenance mode ? #2131

Closed jvermillard closed 6 months ago

jvermillard commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

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 commented 8 months ago

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

boaks commented 6 months ago

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.