Hi everyone,

I've been trying to access clustrmaps.com recently but noticed it is completely non-responsive.

I ran a server status check (screenshot attached), and it confirms that the site has been DOWN for everyone for more than a week with no response from their servers globally.

https://preview.redd.it/j60embe9j85h1.png?width=678&format=png&auto=webp&s=b139ecbd963fa9e176f9834407ea48096b571daf

Given that it's a massive data aggregation site, a week-long total outage is pretty unusual unless something major happened behind the scenes.

• Does anyone know if they officially shut down or went bankrupt?
• Could this be a major backend/database failure, or did they pull the plug due to legal/compliance issues?
• Is anyone else here who tracks web infrastructure noticing any DNS or hosting changes for their domain?

Would appreciate any insights from the community!

Hi, I’m working on a C++17 desktop application for 3D mesh / point-cloud processing. It uses Dear ImGui for the UI, Easy3D for viewer/model handling, and optional CGAL-based geometry algorithms.

I’m mainly looking for architecture feedback from people who have worked on larger C++ desktop apps, immediate-mode GUIs, or async job systems.

I have two related design concerns.

1. UI complexity is concentrated in MainWindow

The app has grown around a central MainWindow class. The implementation has already been split into multiple .cpp files, which helps readability, but the class itself still owns a lot of state:

• dialog open/close flags
• dialog-specific state
• overlay / preview state
• selection state
• operation history state
• AI panel state
• algorithm UI state

So even though the code is physically split, most state still gathers in one central object. My concern is that every new algorithm or tool will keep adding more state to MainWindow, making unrelated features easier to break accidentally.

My current thought is to keep MainWindow as the composition/root object, but extract smaller coordinators/controllers such as:

• DialogCoordinator
• OverlayController
• AlgorithmUiCoordinator
• AiPanelController
• SelectionController
• maybe a small command/event queue for UI actions

I do not want to over-engineer this into a giant global app store. I’m looking for boundaries that fit C++ and immediate-mode GUI code reasonably well.

For people who have refactored large ImGui or desktop C++ applications: what boundary would you introduce first? Would you split by feature, by UI region, by state ownership, or by service/domain responsibility?

2. Async algorithm completion protocol feels fragile

The app has an AlgorithmController that tracks running geometry jobs and result handoff.

For simple jobs, the worker thread can mark the job done when computation finishes.

For visual jobs, it is more complicated. Some algorithms produce live preview / final result data, then set a flag like final_result_ready. The dialog/UI code later decides when the result has settled and when it is safe to finalize it, then commits the result from the render loop.

That split exists for a reason: some final handoff needs to happen on the UI/main thread, after preview/result state has been consumed. But the protocol is currently spread across the service, runner, and dialog. When adding a new algorithm, it is easy to forget one piece.

I’m considering making the lifecycle explicit, for example:

enum class JobState {
    Queued,
    Running,
    WorkerFinished,
    AwaitingUiCommit,
    CommittingResult,
    Completed,
    Failed,
    Cancelled
};

enum class CompletionPolicy {
    CompleteOnWorkerFinish,
    RequiresUiCommit
};