Hi Chris, Personally, I am in favor of the following points:
- Bumping the base Java version to Java 17 - Switching from the JavaX to the Jakarta namespace - Switching to the develop branch However, regarding the switch from Singletons to Dependency Injection, I feel this would be a massive undertaking. We currently rely on a large number of singletons, and refactoring all of them would consume a significant amount of the community's energy while bringing relatively limited benefits. Regarding *replacing the MQTT support with one based on an MQTT client rather than a Broker*: I don't think a direct replacement is necessary. The current MQTT implementation is already decoupled as an independent plugin. You could implement your client-based approach as a new plugin under the external-service package, and we could simply let users choose which MQTT implementation they want to use via configuration. As for *stripping the DataNode into its bare essentials*: Have you outlined what constitutes these "bare essentials"? In my view, apart from the code related to Pipe and Subscription, the rest of the current DataNode essentially belongs to the core read/write functionalities, especially since protocol layers like MQTT and REST have already been extracted. Regarding *allowing inner-VM communication between ConfigNode and DataNode*: Actually, I have a similar plan to develop an embedded version of IoTDB called embedded-iotdb (conceptually similar to SQLite). This plan involves completely removing Thrift and ratis (which would make embedded-iotdb much leaner) and replacing the communication between CN and DN with direct function calls. I wonder if your goal aligns with this plan? Best regards, --------------------- Yuan Tian On Fri, Mar 27, 2026 at 4:18 PM Christofer Dutz <[email protected]> wrote: > Hi all, > > As you know, I have brought up several topics repeatedly over the last few > years. > Things that I personally require to continue using IoTDB. > > > * > Living the base-java-version to Java 17 > * > Switching from JavaX to Jakarta namespace > * > Switching from Singletons to Dependency Injection (Spring) > * > Developing on „develop“ and not „master“ (We voted for that years ago but > never did the switch) > > As recently all of them have been denied or ignored, I have created a > personal fork where I applied these changes. > > So now I’m asking … is there interest in this from side of the Project? If > yes, I’m happy to whip up a PR (Even if it’s most probably a HUGE one). If > not, I’ll probably keep on working on my fork and keeping it closed but > stop going the extra mile for making it able to go back into IoTDB and > fully go nuts about it, forming it fully into what I would like it to be > like. > > > * > Replacing the MQTT support with one based on an MQTT client and not an > MQTT Broker. > * > Stripping DataNode into it’s bare essentials > * > Moving all current DataNode extensions into separate plugins. > * > Allowing inner-VM communication between config- and data-node. > > Chris >
