Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
<p>Uniform sampling from convex polytopes in high dimensions is very useful in many scientific fields and applications. The package volesti is a C++ software with an R interface in CRAN which provides 4 geometric random walks for uniform sampling from convex polytopes among other algorithms in the field of geometric statistics. A classical and difficult problem is to know when the Markov chain converges to the target distribution in order to stop sampling. Diagnostics are tools that can be used to check whether the quality of a sample generated with an MCMC algorithm is sufficient to provide an accurate approximation of the target distribution. The goals of this project are to provide: i) three diagnostic tools for a random walk to check convergence to the target distribution, ii) efficient implementations of all the known geometric random walks for uniform sampling from convex bodies, that are not implemented in volesti and iii) an improved implementation for Billiard walk which is already implemented in volesti. The diagnostic tools would allow us to compare the mixing time of various random walks, which is a classical and hard problem in high dimensional statistics.</p>
<p>The Taverna suite is consist of Taverna Engine, which handles both Taverna Workbench and the Taverna Server. Taverna Server is used to execute remote workflows and workbench provides GUI for create, run, import workflows.This concept allow scientists who has limited knowledge in computing, limited technical resources to do complex process on Data. Also Taverna engine can be run on standard Windows, Linux or Mac OS. At the moment Taverna workflows are constructed using SCULF2 API. So, Tavera Engine can’t execute other workflows other than Taverna workflows. This is where CWL comes in ,The Common Workflow Language (CWL). CWL allows one description of a workflow to be run on multiple different platforms as long as they all support CWL. " CWL builds on technologies such as JSONLD and Avro for data modeling and Docker for portable runtime environments ". The project mission is to bring CWL UI support in the Workbench which is a graphical way to build workflows and one of the steps in Add Common Workflow Language support to Taverna.</p>
<p>Nominatim is a software used to process geocoding requests on OpenStreetMap data. The software uses its own database schema which differs from the one used by the main OSM database. As a result, Nominatim processes OSM data in a way that allows to discover a lot of inconsistencies. The idea of the project is to build a Quality Assurance tool which will analyze the Nominatim database and extract the data errors to multiple formatted JSON files. The errors will be extracted based on a set of rules defined inside the tool. At first, the exported JSON files would be used to present all the errors data to OSM mappers through a visual map on a website. Thus, this tool will help OSM mappers to correct wrong data by taking advantage of the Nominatim internal data structure. The tool should be designed in a way that allows to add new rules easily. In the future, it should also be possible to extract the reports in some other formats in a flexible way. The process would be run once per day against the Nominatim database, stopping regular updates during its execution, so it is crucial that it is optimized to run fast.</p>
Have you ever encountered a frustrating error when browsing a webpage, or perhaps landed on a page expecting to find information about the first computer, only to discover something completely unrelated? When we request a webpage, the server communicates its status through an HTTP response code. If the page is broken or doesn't exist, the server responds with a 404 error code or some other error code in the 4xx and 5xx range, indicating an issue, and 200 OK (or some other status codes in the 2xx range) if everything is good. However, a common challenge arises when the server returns a 200 OK in every case, making it difficult for computers to differentiate between a healthy page and a problematic one. If these problematic pages go unnoticed and are not replaced with their healthy counterparts over time, they contribute to a pervasive issue known as "link rot," leading to the gradual loss of valuable internet information. This work addresses such issues by performing content analysis of webpages to identify potential soft-404s that would otherwise go undetected due to the wrong HTTP status code they return. A prior version of such soft-404 pages is then looked up in the Wayback Machine to replace the link in the Wikipedia article with, if present.
LibreOffice Writer's internal layout engine is extremely intricate and historically dense. This means that attempting to modernize and refactor it is extremely difficult without comprehensive automated tests that account for every possible case. This is precisely why this project is shifting away from conventional bug hunting and instead focusing on an analytical and metric-driven Quality Assurance approach. By utilizing gcov and lcov, it is possible to automatically determine which C++ execution branches in the core layout module (sw/source/core/layout/) are not yet tested. By reverse-engineering test documents that specifically invoke these branches, it is then possible to create comprehensive CppUnit tests that utilize parseLayoutDump() and XPath queries to mathematically validate and "lock in" the correct internal XML layout tree representation. The final deliverables will be continuous lcov coverage reports that demonstrate quantifiable metrics, custom-engineered test documents (.odt/.docx), and dozens of high-quality C++ layout tests that will be merged into sw/qa/extras/layout/. This project will create a comprehensive safety net that is significantly cheaper, easier, and safer for all core developers.
<p>KDE Connect has recently launched an SMS Messaging app for the desktop which uses KDE Connect to synchronize all the existing conversations from the remote device. In its current state it can:- Show a list of existing conversations and the corresponding conversation history. Send and display SMS. Send SMS to only existing contacts and conversations on the remote device. Display (not send) group messages. However, It is very limited to MMS and can only support showing text. It cannot send and display pictures, audio, video and other kinds of attachments, also users cannot reply to multi-target conversations. Considering the importance of sharing multimedia files and group messages, the SMS client becomes very limited in use. This project aims to improve MMS support with the integration of sending multi-target MMS by re-working the current implementation of sending SMS and UI support using Qt Multimedia library. By the end of this project, SMS client will be capable of sending and receiving MMS, will be able to send multi-target MMS with the capability to view pictures, video/audio in SMS app and the capability to download attachments.</p>
This project aims to bring GraalVM native-image support to JabRef, starting with JabKit and its core dependency JabLib, and then extending to JabGui, JabLS, and JabSrv based on feasibility. Currently, JabKit is distributed using JPackage and JBang, which leads to relatively slow startup time for a CLI tool. Native-image can compile Java applications into standalone executables with faster startup, but applying it to a large modular project like JabRef is challenging, especially due to runtime issues. Based on preliminary experiments, the main difficulty is not compilation but runtime compatibility. Dependencies such as Lucene, PDFBox, and JGit can compile successfully but fail at runtime due to dynamic class loading, reflection, or native library requirements. This project follows an incremental approach. First, it establishes a minimal native-image build and testing setup. Then, it enables a subset of JabKit functionality and gradually expands support by resolving dependency issues. Finally, it investigates feasibility for JabGui, JabLS, and JabSrv. Expected deliverables include a working JabKit native executable, feasibility results for other components, and documentation on dependency compatibility and native-image configuration.
<p>AFL++’s mutation engine is optimized for compact data formats, such as images, multimedia, compressed data. However, the current AFL++ does not support grammar and therefore struggles with highly-structured inputs like PHP, JavaScript, or HTML . Although AFL++ allows users to define a dictionary, including language keywords, to help generate inputs, it still lacks more structured descriptions of the underlying syntax.</p> <p>To tackle the existing limitations of AFL++, the main goal of this project is to develop a pluggable grammar mutator that is integrated with AFL++’s mutation engine and can efficiently generate grammar-aware inputs. On one hand, like Nautilus, we want to combine grammar mutators with AFL++’s mutation engine. Also, we want to avoid the potential limitation of Nautilus: “over time Nautilus de-generates to structure-unaware greybox fuzzing”, as indicated by AFLSmart paper. On the other hand, we want to generate test cases efficiently as F1 fuzzer. Furthermore, to improve usability, we will develop a program generator that takes the grammar model as input and generates a mutator library, which is based on AFL++’s custom mutator APIs.</p>
Moving towards enforcing stricter types for the django backend endpoints by using @typed_endpoint decorator instead of the current @has_request_variables. Transitioning to pydantic's data validation provides much more flexibility with the availability of base models as well as different validators. Defining more coherent data classes and base models for complex parameters like 'narrow' will help improve the overall usage experience of these parameters in the entire codebase. Proposed Solution I would start by prioritizing the data driven endpoints, especially those involving authentication and user profile creation and updation as these endpoints deal with a lot of sensitive data and will benefit the most from data validation. My next focus would be the message endpoints because these endpoints deal with large amounts of traffic and need to have robust types in order to avoid any issues with sending/updating messages, their flags and reactions, etc. Switching the streams and dms over to @typed_endpoint will help better manage the streams and make them ready to easily implement the changes proposed in migrating Zulip’s direct message recipient data structures along with any other future plans for these sections. While migrating these endpoints, I will simultaneously add more robust test cases to test all the different data validators.
<p>This proposal consists of a few tasks that implement new features for Kapitan which I believe will add value to the software. Task 1: dependency management With this feature, kapitan users will be able to fetch sources via HTTP[S] and/or git during compilation into specific targets. This will allow them to manage online dependencies much more easily.</p> <p>Task 2: support for Helm chart import This will allow existing Helm users to import their charts into kapitan projects and render the charts together with the values set in the kapitan inventory to compile into a target. This integration will make it easy for users to switch to kapitan from Helm.</p> <p>Task 3: kapitan binary Kapitan exists as a pip package to be used in CLI and as a Docker image. Users have pointed out that having a portable binary for Kapitan would be very helpful. This task aims to meet such needs by packaging kapitan into a static binary with the use of third-party build tools.</p> <p>Task 4: json schema validation for k8s Kapitan, just as it has its own channel in k8s slack community, is used by a large number of k8s users. This feature enables pre-checking of compilation output of k8s configuration files.</p>
The project aims to make the following changes to the talawa-api: Enforce a stricter, standard graphql-pattern to get rid of the current anti-pattern nature that exists in the API. Resolve the relations that exist within the application optimally. Caching data for MongoDB collection entities having significantly higher number of read operations than write operations using Redis in memory Cache. Monitoring changes in the API schemas and relaying the changes to the client apps using Graphql-Inspector for better versioning migrations. Implement Data Normalization on the Client side(admin-portal and talawa mobile app) cache-store using Apollo Client Normalization. Providing a standard, scalable Error Handling mechanism within the graphql API using unions and interfaces to allow a consistent relay of Errors to the Client apps which will allow them to have more control over customizing UI behavior in case of errors. Implement stricter and simpler RBAC in the API resolvers in line with the business logic. Implement SSL in the client-server layer to encrypt all data exchanged between the client apps and API. Encryption of PII data within the SSL layer and in the Database at rest for added security using AES algorithm to encrypt and decrypt PII fields.
Sometimes users will edit the `kcl.mod` file in the IDE to update project dependencies. The integration between LSP and KPM needs to be strengthened, it mainly includes two parts of functions. - According to the content written by the user in the kcl.mod file, the IDE automatically calls the `kcl run/mod add/mod metadata` and other functions, and feeds back the results in the IDE. - According to the user's operations in the command line, the changes of `kcl.mod` and project content are synchronized to the IDE. examples: 1. When users update kcl.mod in the IDE, the required dependencies are automatically downloaded. 2. When users use the kpm tool to update dependencies, the IDE can be updated (recompiled). For example import k8s # Error: Module not found use `kcl mod add k8s` to download the dependency `k8s`. kpm will download the k8s package and then the IDE errors will be eliminated Expected Outcome: - Complete at least the following parts: - IDE triggers automatic dependencies updates of package management tools. - Automatic synchronization of kcl.mod files. - IDE users actively trigger dependency downloads, it looks like: a button or link for user to download the missing dependencies. - After the dependency update is complete, the IDE triggers a recompile to clear the error
<p><strong>Modelica</strong> is an object-oriented and declarative language specification for description/modeling of dynamic systems (mechanical, electrical, thermal, mixed, etc.). <strong>Scilab</strong> uses it inside <strong>Xcos</strong> to describe more complex blocks/components, taking advantage of existing compiler/translator implementations to generate correspondent <strong>C</strong> code for actual simulation.</p> <p>For now, <strong>Modelica</strong> in <strong>Scilab</strong> is managed by an out-of tree compiler developed by <strong>LMS</strong> released under the <strong>GPL</strong> license, which is not actively maintained and support only a subset of the current language specification. The idea of this project is to allow the usage of <strong>OpenModelica</strong>’s <strong>OMCompiler</strong> (<strong>omc</strong>) as an alternative. Being a more up-to-date solution, <strong>omc</strong> integration would provide <strong>Scilab</strong>/<strong>Xcos</strong> the ability to use more advanced features, and avoid bugs, issues and maintenance burden of the current <strong>modelicac</strong> compiler.</p> <p>Adapting <strong>Xcos</strong> blocks to support the <strong>FMI2 API</strong> standard would allow not only omc-generated code to be called but also any other FMI2-compliant applications to be easily integrate in the future.</p>
<p>This project aims to build a ROS gazebo simulation framework to display robot navigation using OMPL. The framework include OMPL GUI, navigation node, obstacle plugin and robot model.</p> <p>OMPL GUI should manage the navigation’s start or stop and set all the parameters such as robot type, start and goal pose and different OMPL planner. The tool can publish relevant message or subscribe service to change parameter.</p> <p>Navigation receives configure from GUI node and obstacle information from gazebo. It calls the OMPL api and publish ROS path message. If the robot model is devoted to route, this node should update the new planning path based on new robot pose.</p> <p>Although it just needs a known scenario in claim, I think it is convenience that we can change obstacle position freely. The gazebo plugin for obstacle can publish self-information or subscribe navigation’s service to change obstacle information.</p> <p>When navigation node publish the Path message, a robot model and its path following function is needed to complete this motion. Conveniently, I will use robot models in the JdeRobot such as turtlebot and adrone.</p> <p>Integrate all the above and implement the integral ROS gazebo simulation framework.</p>
This proposal aims to implement HTTP/3 communication for Dubbo Triple in the Go language environment, enhancing the connection management capabilities of the Triple protocol in dubbo-go. The proposal will address the compatibility issues between Triple communication in dubbo-go and dubbo-java by implementing keep-alive functionality at the Triple protocol layer. Additionally, the proposal plans to organize and standardize the error codes of the Triple protocol and output necessary log information. By developing a Triple HTTP/3 server and client, seamless and high-performance communication between Dubbo Java and Dubbo Go over the HTTP/3 protocol will be achieved. We will design a connection pool to effectively manage Triple connections and ensure the validity of connections through a PING-PONG mechanism between the server and client, thus realizing keep-alive functionality. Furthermore, the error codes of the Triple protocol will be standardized according to Dubbo Java's standards to facilitate developers in obtaining detailed log information during the debugging process. The final deliverable of the proposal is to achieve high-performance, barrier-free communication between Dubbo Go and Dubbo Java through the Triple protocol, ensuring perfect compatibility and support for interaction via the HTTP/3 protocol. Users will be able to enjoy flexible keep-alive functionality and improve debugging efficiency through standardized error codes.
Abstract: This proposal outlines a plan to enhance Meshery's relationship evaluation capabilities by implementing client-side policy evaluation using WebAssembly. By integrating OPA's WebAssembly compilation capabilities into Meshery's UI, I aim to enable real-time evaluation of complex Rego policies, providing users with immediate feedback on configuration changes and policy compliance. This enhancement will significantly improve the user experience when designing their designs and will make the policy evaluation distributed hence reducing load on a meshery server Problem Statement Meshery currently doesn't support evaluating policies in real-time on the client side. The existing approach ( relying on the rest api interface exposed by meshery-server) introduce s latency when policy evaluation occurs server-side, limiting the responsiveness of the UI when users make configuration changes. Additionally, as policies become more complex and numerous, the ability to quickly validate configurations against these policies becomes increasingly important for a smooth user experience. Proposed Solution: Use opas capibilty to compile rego policies directly into wasm plans and then integrate the evaluation process in ui using OPA's JavaScript SDK, which provides a simpler way to load and evaluate Rego policies compiled to WebAssembly. This approach is more lightweight and performant . Deliverables : - Real time evaluation of policies in ui - Keeping the support for both targets of evaluation backend or realtime on frontend - Making the evaluation responsive and performant by implementing webworkers , caching
Users often encounter calls, SMS messages, and links across various mobile platforms, including browsers, social media, and messaging apps. However, when doubts arise regarding the legitimacy of these communications, such as suspicions of phishing attacks or the presence of malicious links, users currently lack a dedicated platform for submitting and reviewing such content. This absence of a centralized platform leaves users vulnerable to potential threats, as they lack a reliable mechanism to report and verify suspicious communications. Consequently, there is a pressing need for the development of a dedicated platform where users can submit calls, SMS messages, and links for review by trusted authorities or community members. Such a platform would empower users to proactively address security concerns, enhance collective awareness of potential threats, and contribute to the creation of a safer digital environment for all mobile users. To address this pressing issue, we propose the development of a comprehensive mobile application equipped with automatic detection capabilities tailored to identify and mitigate spams and scams. In addition to its automated features, the application empowers users to manually contribute instances of suspicious content encountered on diverse platforms, fostering a community-driven approach to combating online fraud. Complementing the mobile app, a dedicated web application will cater to administrative users, providing them with the tools and resources needed to conduct thorough reviews of reported instances. Through a systematic review process, pertinent information about identified spams and scams will be meticulously documented and stored in a secure database, facilitating further analysis and informing future detection strategies.
The project aims to address a common challenge faced by both beginner and advanced programmers: understanding and learning from mistakes in code submissions. Traditional autograding systems often provide generic feedback, which may not be sufficient for students to grasp the root causes of their errors and improve their coding skills effectively. To overcome this limitation, the project proposes the development of a sophisticated system that can analyze code submissions comprehensively. This system will consist of custom drivers designed for each programming problem, capable of detecting various types of errors and providing tailored explanations for them. These explanations will cover not only low-level syntax errors but also higher-level issues such as algorithmic design flaws or incorrect usage of data structures. Moreover, the project includes the creation of an intuitive interface with a structured roadmap covering programming topics from basic to advanced levels. This interface will offer a gamified learning experience, complete with progress indicators and visual feedback mechanisms to keep users engaged and motivated. By integrating the custom drivers and feedback pipeline into this interface, the project aims to provide a seamless learning experience for users at all skill levels. Utilizing open-source tools like Monaco code editor and Judge0 for code execution ensures compatibility and accessibility across different platforms. Additionally, the project emphasizes continuous feedback and refinement through interactions with mentors, instructors, and users. This iterative approach allows for the continuous improvement of the system, ensuring its effectiveness in assisting learners in understanding programming concepts and improving their coding skills.
BRL-CAD is a battle-tested Constructive Solid Geometry (CSG) engine, but it currently lacks a native, bidirectional interface for headless command execution, creating a massive barrier for modern web integrations and AI agents. This project proposes building BRL-CAD’s first native, extension-agnostic C++ Local IPC (Inter-Process Communication) API. By securely binding a stdio-based pipe listener to the main event loop and leveraging native libbu utilities for memory-safe string parsing, this infrastructure will allow users to safely pipe commands directly into the libged database engine. Designed with a "generic passthrough" architecture, it avoids hardcoding 400+ command schemas and ensures frictionless portability to BRL-CAD’s upcoming MOOSE/Qt interface. Alongside this foundational API, the project delivers a robust Model Context Protocol (MCP) server to establish BRL-CAD's first native Agentic AI integration. Operating externally as decoupled Python-based FastMCP middleware, this daemon bridges the legacy C-engine with modern Large Language Models. Rather than embedding a bulky AI chatbot inside MGED, the user interacts through their preferred external MCP client (like Cursor IDE or Claude Desktop), which routes commands directly into BRL-CAD's new background IPC pipeline. This empowers users to seamlessly query native documentation, automate batch database tasks, and debug spatial relationships using conversational commands, drastically lowering BRL-CAD's onboarding friction.
Apache ShardingSphere is positioned as a Database Plus, and aims at building a standard layer and ecosystem above heterogeneous databases. It focuses on how to reuse existing databases and their respective upper layer, rather than creating a new database. The goal is to minimize or eliminate the challenges caused by underlying database fragmentation. ShardingSphere parser engine is the core of ShardingSphere, It helps users parse a SQL to get the AST (Abstract Syntax Tree) and visit this tree to get SQLStatement (Java Object). At present, this parser engine can handle SQLs for MySQL, PostgreSQL, SQLServer, openGauss and Oracle. However, there are still many statements that are not supported yet. Therefore this project proposes to Solve unsupported Postgres sql about alter statements for ShardingSphere parser and also proofread and optimize the grammar wherever needed. This project would require to proofread through DDLStatement.g4 to analyze existing grammars and optimize them (essential), write grammar for unsupported alter statements referring to the official PostgreSQL documentation (essential), implement visit methods for the statements (essential), add new corresponding SQL cases and expected parsed results (essential), Run SQLParserParameterizedTest and UnsupportedSQLParserParameterizedTest to make sure there are no exceptions (essential). Successful Implementation of the project will add proper support for PostgreSQL Alter Statements ensuring there are no exceptions for the following statements, ALTER OPERATOR, ALTER POLICY, ALTER PUBLICATION, ALTER ROUTINE, ALTER RULE, ALTER SCHEMA, ALTER SEQUENCE, ALTER SERVER, ALTER STATISTICS, ALTER SUBSCRIPTION, ALTER TABLE, ALTER TEXT SEARCH,ALTER TRIGGER, ALTER TYPE, ALTER VIEW. This project will significantly improve the ShardingSphere parser engine.
Accessing medical data through the care web app can be daunting for patients in rural or remote areas who often face challenges with digital literacy, internet connectivity or lack of access to computers. Currently, retrieving appointments, health records etc requires users to log in and navigate the care web app, which makes it difficult for those with limited digital exposure to access their essential medical information. This project introduces an Instant Messaging wrapper for the care EMR, built as a django plugin. Which allows patients and staff to securely fetch medical records, check appointments etc and receive alerts and notifications through familiar, easy to use messaging apps like WhatsApp. To ensure HIPAA security compliance, the system uses a 2 step authentication process which includes (1). matching phone number and (2). verifying requestor's date of birth. It will also include redis based caching, ratelimiting of requests to prevent abuse and async task management via celery to handle sending of notifications in the background. A frontend plugin will also be developed to give staff the ability to easily send alerts and notifications and allow patients to download PDFs, such as medications and lab reports. Deliverables: 1. A functional, django based backend plugin, capable of securely serving patient and staff queries via various instant messaging providers. 2. A frontend developed using care_hello_fe to manage notifications and handle PDF downloads. 3. Proper tests utilizing pytest and Playwright for both the backend and frontend. 4. Complete and comprehensive documentation using sphinx and swagger, along with setup guides and demo videos. 5. Production ready deployments of both the backend and frontend plugins integrated within care.
The recent efforts of the `scala-wasm` project have made it possible for Scala to use the WebAssembly Component Model binary format as a compilation target. Although, the implementation has not yet been finished, it is already possible for developers to run Scala code on Wasm runtimes. In order for the Scala language to succeed in the Wasm ecosystem, core libraries which rely on platform APIs must be ported to the Wasm/WASI platform. The goal of this project is to prototype porting the core parts of the Cats Effect and FS2 libraries to the Wasm/WASI platform. The CE runtime prototype will be single-threaded and based around `wasi:io/poll`. The end result is expected to be similar to the (now-replaced) single-threaded LLVM runtime which used a `libuv`-style event-loop. The FS2 porting effort is going to focus on `fs2-core` and the `network` and `file` APIs from `fs2-io`. As a part of this project, a standalone reimplementation of java.nio.file API will be developed as a separate library. Planned Deliverables: 1. A working prototype of Cats Effect's single-threaded runtime compiling and running on Wasm/WASI free of glue JavaScript code. This prototype will serve as a basis for an upstream implementation. 2. Prototype port of the core FS2 module and the fs2.io.file and io.network APIs. 3. A standalone library reimplementation of JDK file APIs for WASI. Initial scope of the implementation will be adjusted to the needs of the fs2.io.file port. 4 An extensive documentation of the project. 5. A report regarding implementation details and findings discovered over the course of the project which will help with further porting efforts of Scala compilers and other platform-dependent libraries. 6. Wasm test environment and CI created for this project can upstreamed to sbt-typelevel so that it can be used in other projects.
The KomMonitor web client, a tool for geospatial data monitoring in urban planning, is currently based on AngularJS and requires a complete migration to the modern Angular framework to improve maintainability, scalability, and ease future contributions. While migration started previously, significant parts remain in AngularJS, and foundational issues like specific AngularJS patterns ($rootScope, $compile) and JavaScript files hinder the direct use of standard upgrade tools. Solution: This project aims to fully migrate the KomMonitor web client from AngularJS to Angular. The approach involves: 1. Addressing the foundational roadblocks identified by analysis tools (e.g., refactoring $rootScope usage, eliminating $compile, converting JavaScript to TypeScript). 2. Incrementally migrating remaining AngularJS components and services to Angular, leveraging ngUpgrade within a hybrid architecture during the transition. 3. Implementing modern Angular best practices, including modular architecture, dependency injection, and potentially lazy loading. 4. Refactoring components using design patterns like Observer (RxJS), Facade, and Container-Presenter to improve structure and data handling. 5. Ensuring UI consistency using ng-bootstrap. 6. Establishing a robust testing strategy encompassing unit, integration, and end-to-end tests using frameworks like Jest and Cypress. Deliverables: 1. A fully migrated KomMonitor web client codebase, transitioned from AngularJS to Angular. 2. Resolution of key AngularJS patterns ($rootScope, $compile) and conversion of necessary JavaScript files to TypeScript. 3. Migrated and optimized components/services adhering to modern Angular standards and design patterns. 4. A comprehensive test suite ensuring application stability and functionality post-migration. 5. Updated documentation reflecting the migrated codebase. 6. Final project code, documentation, and evaluation report.
<p>OpenEverest is an open-source cloud-native database platform that helps developers deploy and manage PostgreSQL, MySQL, MongoDB, and other databases on Kubernetes. In V2 it uses a plugin architecture where database providers define their UI through declarative YAML schemas (UISchema in Provider CRD). Currently, plugin developers have no integrated tool for developing and testing these schemas — the only way to see the rendered result is to deploy a full Provider CRD into a running Kubernetes cluster, making the development cycle slow and error-prone. This project aims to build a Plugin Developer Playground — a page inside OpenEverest where plugin developers can write UISchema YAML, see the rendered form in real time, validate the schema structure, inspect the post-processed API payload, and save/share schemas, all without deploying to a cluster. The mentee must solve the CSP compatibility problem by either choosing a CSP-compliant code editor or proposing an isolation architecture (e.g., sandboxed iframe) that keeps the main application's strict security posture intact.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>Split-pane YAML editor with syntax highlighting and live form preview using the existing `UIGenerator` component</li><li>Real-time schema validation: YAML parsing errors and structural validation against the `TopologyUISchemas` type, with inline error markers in the editor</li><li>Live form rendering with stepper navigation through schema sections and topology switching</li><li>Dynamic field support: existing API provider fields load real data from the running OpenEverest instance; new/unknown provider types can be mocked</li><li>Output panel displaying the JSON payload after form data post-processing</li><li>CSP-compliant solution</li><li>Unit tests for core logic (schema validation, persistence, mock data injection) and component tests for key panels</li><li>Plugin developer guide for using the playground and the UISchema format</li></ul>