Explore Projects

This project aims to deliver comprehensive, end-to-end non-uniform grid support for MethodOfLines.jl. Currently, basic advection schemes lack graceful error handling for ill-posed boundary conditions, and advanced high-order schemes (specifically WENOScheme) completely lack non-uniform method dispatch, leading to fatal compilation errors on irregular domains. The proposed solution utilizes Julia's multiple dispatch to route non-uniform grids to a newly developed, isolated mathematical weight calculator within the WENO module, ensuring zero breaking changes for existing uniform grid users. Key deliverables include refactored basic advection schemes with robust well-posedness validation, a native non-uniform WENO implementation featuring dynamic smoothness indicators and negative weight regularization, rigorous L₂ convergence tests, performance benchmarking, and comprehensive documentation to enable highly precise real-world physics simulations.

Sampling from high-dimensional convex polytopes is a fundamental problem with applications in statistics, machine learning, optimization, and systems biology. Modern libraries such as VolEsti provide a rich collection of geometric random walk algorithms; however, there is currently no unified, extensible, and reproducible framework for benchmarking these methods in practice. In my recent MSc thesis, I conducted a large-scale empirical comparison of state-of-the art sampling algorithms across multiple software ecosystems. This work revealed a clear gap: while many algorithms exist, there is no standardized way to evaluate them under consistent configurations, geometries, and diagnostics. The goal of this project is to design and implement a complete benchmarking suite for VolEsti, enabling systematic, reproducible, and extensible evaluation of geometric random walks. The framework will support configurable experiments, advanced diagnostics, and integration with Python tools for visualization and analysis. Ultimately, we aim to implement a research-grade benchmarking platform where any algorithm can be evaluated quickly and thoroughly and every new suggested algorithm can be easily compared to existing methods.

<p>The project will include adding new approaches to already existing triangulated mesh simplification framework of CGAL.</p> <p>The current approach depends on a method developed by Turk &amp; Lindstrom, which is based on edge collapsing. The first suggested new approach is based on the algorithm developed by Garland &amp; Heckbert. It uses vertex collapsing instead of edge collapsing as the primitive operation. In their method, they collapse vertices that share an edge or that are close to each other. In each iteration, a pair of vertices get collapsed resulting in a new vertex. They choose the pair that will be collapsed based on an error metric expressed as a quadratic function. They choose the pair that minimizes the error metric. A parallel version of Garland &amp; Heckbert will also be implemented.</p> <p>After implementing this approach in CGAL, CGAL’s triangulated mesh simplification framework will be compared to other libraries in terms of runtime and memory usage. (OpenMesh, MeshLab, PCL)</p> <p>This cycle will be repeated for other mesh simplification methods.</p>

This project aims to enhance the SPDX Online Tool by improving its functionality and efficiency for license submissions. The project proposes adding features such as automatic creation of pull requests and .txt test files, improving error handling, adding unit tests and GitHub API interaction tests with mock, and creating a base reusable Django app to reduce development efforts. The objective is to streamline the license submission process, reduce manual effort, save time, and enhance productivity. The project proposes clear deliverables such as generating a .txt test file, differentiating exceptions from license submissions, adding or fixing unit tests, and improving error handling. The project will contribute to the open-source community and will provide a learning experience for the software engineering student working on the project. The choice of SPDX as the organization to work with is motivated by its mission to create a standard format for communicating the components, licenses, and copyrights of software packages and its strong community of developers, contributors, and users committed to driving innovation in the field of software licensing.

<p>The package mcmcse is the leading package for estimating Monte Carlo standard errors for Markov chain Monte Carlo and reliable calculation of effective sample size. The package performs multivariate output analysis on extremely high dimensional Markov chains of the order of a thousand components and lengths exceeding millions, experiencing bottlenecks in efficiency. The primary goal of the project is to systematically identify and clear efficiency bottlenecks via detailed benchmarking and testings. This project will focus on improving the implementation of critical subroutines, like batchsize() and mcse.q(), of the package. This would involve migrating to Rcpp, parallel implementation of functions and implementing alternate algorithms for the task. In addition, improvements to the existing implementation by correcting for numerical instabilities, Rcpp sugar implementations, solving for error or warning messages in corner cases, updating documentation and developing a class identifiable with the output form an integral part of the project. A list of additional tasks specific to certain functions will also work towards improving efficiency and accuracy of the package.</p>

The ECC State Machine Editor in 4diac-IDE has not received the usability improvements applied to other editors like the FB Network Editor. Engineers face friction points: incorrect state placement at zoom levels, strange spline trajectories in transition routing, unreliable Ctrl-drag transition creation, and missing error feedback for invalid conditions. This project takes a three-phase approach: (1) systematic usability analysis and codebase foundation cleanup, (2) fixing identified bugs, and (3) enhancements including Canvas Direct Edit for transition conditions, Smart Snapping, and ECC Live State Highlighting during debugging. Deliverables: Usability Analysis Document, bug fixes (spline trajectory, Ctrl-drag, error feedback, marker navigation), 6+ enhancements, all submitted as focused PRs with documentation and a final project report. Pre-GSoC work already completed: 6 PRs merged including zoom coordinate fix, CreateTransitionCommand cleanup, and documentation improvements — all under direct guidance of mentor Alois Zoitl.

<p>KIO framework is used by KDE applications to provide file management abilities. This framework provides almost all file management functions that one will ever need. However it doesn’t provide any support for file management as a privileged user. So whenever there is a need to perform file management tasks with escalated privileges the application simply shows an error. A casual user may not see it as a problem but for power users, sysadmins, developers this is a huge impedance. Many users get around this by starting the whole application as root. Running Qt/KDE GUI solves the issue but its a very dangerous solution. Dangerous because if not handled properly it can cause irreversible damage to the the system. To address this issue some KDE applications are disabling being executed as root. For example, the next versions of Dolphin and Kate will show an error message and exit when started with root privileges.</p> <p>Polkit is just the tool which can solve this problem. It is the standard framework used by Linux desktops to grant privileged actions to unprivileged processes. The goal of this project is to add Polkit support in KIO and further integrate it in dolphin.</p>

This project focuses on improving the TaskWarrior Flutter mobile application by reducing technical debt, improving the Rust–Flutter integration, and expanding core TaskWarrior functionality on mobile platforms. The current codebase contains legacy synchronization components, incomplete Rust FFI features, and an unstructured project layout that makes maintenance and feature development difficult. The project will remove the deprecated CCSync synchronization layer and unify synchronization through the TaskChampion Rust backend. The tc_helper Rust library will be refactored to improve build configuration, modular structure, cross-compilation, and to expose missing task attributes to the Flutter application. The Flutter project will also be reorganized into clear modules separating legacy Taskwarrior 2.x code from the TaskChampion implementation. Additionally, a mobile reporting engine will be implemented to support Taskwarrior-style filtered reports and user-defined configurations. A GitHub Pages website with automated nightly build tracking will also be created, along with targeted UI and UX improvements based on community feedback. Deliverables include synchronization refactoring, Rust library improvements, Flutter project restructuring, a reporting engine, project website, and UI/UX enhancements.

Thousands of bioinformatics workflows registered on public platforms like Dockstore and WorkflowHub cannot run on modern cloud platforms. Not because the science is wrong, but because the engineering hasn't caught up. Missing containers, hardcoded paths, HPC-specific executors, and unstructured inputs and outputs make these workflows incompatible with GA4GH's WES standard and cloud-based research platforms. Workflow Clinic fixes this automatically. It is a Python-based CLI tool with two core components. The Workflow Critic scans a workflow repository, runs a deterministic rule engine followed by an optional AI agent team, and produces a structured diagnosis.json report identifying every cloudification gap with severity levels and remediation suggestions. The Workflow Doctor reads this report, applies fixes directly to the workflow files using a 3-layer strategy (AST-based, regex-based, and AI-assisted as a last resort), and opens Pull Requests to propose the changes. GitHub interaction is purely optional examine and fix work fully offline without any credentials. When a GitHub PAT is provided, the tool can additionally publish findings as GitHub issues and open Pull Requests. Without a PAT, the same outputs are generated locally as issue.md and fix.md files.

<p>IMPACT User-friendly QA platform for a given DBpedia resource and specifically about pandemic in real-time.</p> <p>GOALS To improve the DBpedia Sparql for real-time monitoring of pandemic situations near the users and the interested country by the users. Compile pandemic data and wikidata for answering users' questions by query databases, and support research and development in the healthcare field related to model predictions and vaccine development.</p> <p>DESCRIPTION As Google engine can answer any question, DBpedia Sparql can query databases and answer questions using Wikipedia resources. The COVID-19 pandemic is an ongoing global pandemic, and humans would need to co-exist with the viruses. We should compile the public wikidata related to coronavirus and learn from them. The aim of this project is to update DBpedia Sparql tool for answering questions related to wikidata and specifically about the coronaviruses. Thus, the improved DBpedia Sparql tool would provide better understanding of the coronavirus pandemic for the public, and serve as a platform for research and development in the public healthcare field.</p> <p>WARM-UP Git repo: <a href="https://github.com/guang-zh/coronavirus_info_app.git" target="_blank">https://github.com/guang-zh/coronavirus_info_app.git</a></p>

The core external libraries that power Unikraft (musl, lwip, and gcc) are currently a few years out of date. This creates technical debt and prevents developers from using modern C/C++ compiler features. The project aims to solve this by updating these critical libraries to their latest versions: musl to 1.2.5, lwip to 2.2.1, and gcc to 14.2.0. To ensure this update doesn't break existing projects, I will implement Unikraft's new Microlibrary Versioning RFC. Instead of completely overwriting the old libraries, I will add the modern versions as selectable options, allowing users to toggle between the legacy and updated toolchains safely. The core technical work will involve manually rebasing Unikraft's custom patches, fixing new compilation errors, and ensuring network stability. The final deliverables for this project will be: 1). Fully updated, patched, and integrated versions of lib-musl, lib-lwip, and lib-gcc running alongside their older counterparts. 2). Verified stability for complex catalog-core applications (like SQLite, Nginx, and Redis) built using the new toolchain. 3). Documentation explaining how users can seamlessly switch their projects between the legacy and modern library versions.

As an early stage project we’ve biased in favour of documenting the essentials and getting content in place as fast as possible. This has worked well but a side-effect is 3 or 4 different sources of content ( www, docs, rfcs and courseware ). In concert with CNCF technical writing and learning best practices use your UX/web design and technical writing expertise for tremor where we as a team are unskilled - make our content awesome and the user experience exceptional. These are some improvements we did think of, but these are neither complete nor required, more suggestions are welcome: - Unify the different content forms under a single consolidated theme and design - Ease of navigation ( breadcrumbs ) - Preserve markdown for data entry ( we’re programmers ) and keep design separate ( we’re not designers and find this stuff super hard ) - A clean, easy to navigate theme with a focus on user experience - Well integrated with our CI and doc generation tooling ( think gitops for docs and content ) This task would suit a candidate who is interested in `full stack` engineering and the complete software development lifecycle with a specific focus or interest in engineering documentation, web design and communicating well designed content to others with a good user experience - exploiting principles of good technical writing and web design of content management systems for technical content consumers.

The `loo` package is a widely used R package in the Stan ecosystem which exposes a clean API to cross-validate (CV) Bayesian models. As new CV methods and diagnostics are created and adopted by the field, the `loo` package must be updated to support them. Currently different predictive performance measures have different APIs and varying level of supported features. This project is focused on refactoring the API to unify the support for different predictive measures to make all useful features available for all predictive measures to make it easier for the modellers to use the most appropriate measures for their applications. Key technical components will include creating a flexible object which can report multiple metrics and scores. Additionally, we need to create functions to support model comparisons for all these scores and metrics. We will also allow for measures besides log score for LOO-CV to be used under the same, unified interface as existing options and create a consistent loo object for all measures. We will further unify the interface by allowing for non-log score measures for in-sample, test data, and K-fold-CV use cases. We will also be extending the model comparison functions to carry forward information on what measure is being compared, diagnostic data, and information on how to calculate the standard error (SE) of the differences of various measures.

The RISC-V Mentorship Program enables one or more 12-week internship-style projects per session, funded by RISC-V, to match mentors/project leaders together with mentees/interns . Mentees are guided through a series of milestones by one or more project mentors, with whom the mentees meet on a weekly basis. This program pairs one mentee with an experienced mentor to deliver a V8 JavaScript engine port for a 32-bit RISC-V core. The V8 JavaScript engine for RISCV64G has been upstreamed to Chromium recently. As a basic component for the Chromium web browser and node.js, it would enlarge RISCV’s application scenario. Although RV32G V8 port would be quite similar to RV64G V8 port , it is still in the TODO list. Porting and enable the RV32G on V8 will bring the embedded RISCV software ecosystem more applications, make RISC-V embed processors more competitive. Deliverables (bullet list of components and the changes expected): - Turbofan backend implementation - Embedded simulator implementation - Corresponding unit tests implementation - Regression tests pass Acceptance criteria (bullet list with measurable results defined): - RV32G cross-compiled and simulator build on both debug and release configuration should be passed - A helloworld demo should run successfully on both the embedded simulator and a real or emulated hardware (i.e. a real board or QEMU emulation). - 97% of the regression test should pass

Drasi is a Data Change Processing platform that enables developers to detect and react to meaningful data changes using declarative Cypher queries. Drasi excels at complex change detection with unique features like `drasi.trueFor()` (detecting conditions that persist over time) and absence-of-change detection (alerting when expected events don't occur). However, it currently lacks native connectivity to IoT protocols. Drasi Lib provides Drasi's powerful graph-aware decision engine as an embeddable Rust library that can run completely offline on constrained hardware—enabling edge computing scenarios where logic runs directly on sensors and gateways. IoT applications fundamentally need to detect state transitions, but developers typically must write boilerplate code and manage state persistence manually. Drasi's diff-engine handles state management and change computation automatically, emitting events only when meaningful changes occur. MQTT (Message Queuing Telemetry Transport) is the de-facto standard protocol for IoT, used by AWS IoT Core, Azure IoT Hub, and virtually every IoT deployment. Adding MQTT support to Drasi Lib will unlock the entire IoT ecosystem for Drasi users. In this project, the mentee will build a suite of lightweight Rust crates that enable Drasi Lib to communicate with MQTT brokers. They will create connectors to ingest sensor data (MQTT Source), execute local actions (Shell Reaction), and close the control loop (MQTT Reaction).

This project enhances the Archi framework by enabling real-time interaction with HTCondor job scheduling infrastructure and introducing a persistent memory system to enhance conclusions drawn on live data with previously encountered similar situations. Currently, Archi operates without access to live system state, limiting it to generic, non-actionable responses when diagnosing job failures. Additionally, solutions discovered during user interactions are not retained, leading to repeated effort and inefficient troubleshooting. To address these limitations, the project introduces a read-only HTCondor tooling layer that allows Archi to query live job data (e.g., via condor_q and condor_history) and provide precise, evidence-based diagnostics. In parallel, a "solution memory" system will be implemented to store validated fixes from past interactions in a vector storage. These solutions will be indexed, embedded, and retrieved through a hybrid search mechanism, enabling Archi to reuse proven resolutions for similar future issues. The main deliverables include: (1) a secure, read-only HTCondor integration layer with structured outputs and error handling, (2) a suite of agent tools for live job inspection and failure diagnosis, (3) a solution memory database with indexing and retrieval capabilities, and (4) full integration into the Archi agent workflow via tools, supported by comprehensive testing, benchmarking, and documentation. By combining live diagnostics with reusable knowledge, this project transforms Archi from a passive assistant into an active, context-aware agent that improves troubleshooting efficiency, reduces computational overhead, and continuously learns from past incidents.

KerasNLP is a library for building NLP building blocks such as model layers, metrics, tokenizers, text processing/augmentation techniques, etc. I have contributed a few of these modules myself, and would like to contribute more such modules during GSoC. Firstly, I would like to contribute NLP-specific metrics. Here, I plan to implement metrics which are not present in Keras, and which are generally used for NLP tasks. Most of these metrics will be implemented as live training metrics, i.e., they can be input to `model.compile` and computed during training. Hence, the implementation should be "in graph mode". The metrics I wish to implement are: BLEU Score, Word Error Rate [WER], Character Error Rate [CER], CHRF, CHRF++ and BLEURT. Secondly, I wish to add functions for decoding strategies. Text Generation is an important problem in NLP. It encompasses tasks like summarisation, machine translation, story generation, etc. During inference, we need to sequentially decode the output of the encoder-decoder model. This is where these utility functions will help users. I plan to implement popular decoding strategies like Random Sampling, Greedy Sampling, Beam Search, top-k Sampling and top-p (nucleus) Sampling. I also want to add model encoder layers. KerasNLP does not aim to build complete models; it aims to build "building blocks" from which models can be built. Keeping this in mind, some encoder layers which I aim to implement are (these encoder layers can then be stacked up to form the complete model): Reformer and ConvBERT (or gMLP) encoder blocks. Text augmentation means perturbing the samples in the original dataset to increase the size of the training set. This is where native text augmentation layers can be immensely useful. Backtranslation and Contextual Word Augmentation are methods which I will implement. The above modules are explained in details in the proposal document.

The Problem: Spack’s combinatorial flexibility makes exhaustive CI testing computationally impossible. Current CI focuses almost exclusively on "leading-edge" configurations (latest packages with latest dependencies). This structurally excludes off-leading-edge scenarios where older packages meet newer, unbounded dependencies, leaving the ecosystem highly vulnerable to silent API/ABI breakages that users only discover in production. The Solution: This project introduces a Generative AI-assisted testing system to autonomously hunt for high-risk configuration breakages. The architecture treats configuration testing as a feedback-driven sequential decision-making pipeline. First, a data-driven heuristic risk model filters dependency pairs based on structural risk and historical failures. Next, an LLM acts as an iterative hypothesis generator to propose structurally diverse, high-risk abstract specs. Finally, a strict deterministic validation layer ensures mathematical correctness and bounds CI compute costs using Spack's Clingo ASP concretizer and semantic deduplication. Key Deliverables: Metadata Extraction Module: Parses package repositories to identify unbounded dependencies and analyze version gaps. Adaptive Risk Scoring Engine: Classifies package pairs into risk tiers using a multiplicative formula driven by structural signals and historical failure data. LLM Hypothesis Generator: An iterative prompt engine utilizing selective context retrieval and within-run adaptation to propose risky testing configurations. Validation Pipeline: A strict gating system utilizing spack.concretize_one() and 3-layered semantic deduplication to prevent redundant or hallucinated tests. State Management Registry: A unified SQLite database to map historical CI data, track tested configurations, and feed failure patterns back into the LLM context. Integration & Diagnostics: A working spack audit ai CLI subcommand and a heuristic log-triage pipeline.

<p>On the Kyverno website, we want to introduce and document a set of technical outcomes that users can achieve by adopting Kyverno. These outcomes should group together Kyverno’s policy capabilities (validate, mutate, generate, verify images, cleanup) into clear, high-level goals that resonate with platform engineers, security teams, and developers.</p><p><br></p><p>Rather than focusing on individual features, this work will highlight what teams can accomplish with Kyverno in real-world environments.</p><p><br></p><p>Proposed technical outcomes include:</p><p>* Secure-by-Default Kubernetes – Enforce security and compliance policies across clusters automatically</p><p>* Policy-Driven Platform Engineering – Enable golden paths and self-service infrastructure using policy as code</p><p>* Automated Governance &amp; Compliance – Continuously audit, report, and enforce organizational standards</p><p>* Software Supply Chain Security – Verify images, enforce provenance, and reduce risk in CI/CD pipelines</p><p>* Kubernetes Configuration Automation – Use mutation and generation to reduce manual configuration overhead</p><p>* Multi-Cluster Policy Management – Apply consistent governance across distributed and multi-cloud environments</p><p>* AI &amp; Agent Governance – Apply policy controls to AI workloads and agent-driven infrastructure workflows</p><p><br></p><p>Each outcome should connect Kyverno capabilities to real-world use cases, supported by artifacts from the community such as blog posts, talks, policy examples, and reference architectures.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;* A new section of the Kyverno website dedicated to Technical Outcomes, where each outcome includes:</p><p>&nbsp;* A clear description of the problem space and desired outcome</p><p>&nbsp;* Mapping to Kyverno capabilities and policy types</p><p>&nbsp;* Links to supporting resources (blogs, videos, talks, GitHub examples, policy libraries)</p><p>&nbsp;* Optional diagrams or visual flows illustrating how Kyverno enables the outcome</p><p><br></p><p>This section should serve as:</p><p>* A learning and onboarding resource for new users</p><p>* A messaging bridge between technical features and business value</p><p>* A foundation for future content, including case studies, solution briefs, and AI-driven policy generation experiences</p><p><br></p>

<p>Jaeger is the industry-standard platform for distributed tracing. As microservice architectures grow complex, finding root causes in massive trace data becomes increasingly difficult. While Phase 1 of this initiative established a baseline AI assistant for natural language search, the system currently relies on hard-coded capabilities. This project (Phase 2\) aims to transform the Jaeger AI agent from a static chatbot into an extensible, user-programmable platform. The primary objective is to implement a "Self-Service Skills" framework, architecturally similar to "Claude Code Skills." This will allow end-users to teach the Jaeger AI new debugging workflows (e.g., "Analyze Critical Path" or "Detect N+1 Queries") by simply adding configuration files containing system prompts and logic rules, without needing to recompile the Jaeger binary. The applicant will build this extension within the Jaeger v2 (OpenTelemetry-based) architecture, utilizing **LangChainGo** to orchestrate interactions with Language Models (SLMs/LLMs). This project bridges the gap between generic AI reasoning and domain-specific observability expertise.</p><p><br></p><p>**Expected Outcome:**</p><p>&nbsp;- **Skills Engine Implementation:** An approach compatible with our [BYOA (bring your own agent)](https://docs.google.com/document/d/1qD0OpyRfq-JbO6MCB5gmVxsdPcpPhxz1R_pPnKDdYOg/edit?tab=t.0#heading=h.qgr5ifum0a9m) direction that dynamically discovers, validates, and loads user-defined "Skills" (prompts and tool definitions) from configuration.</p><p>&nbsp;- **Smart Analysis Features:** A polished implementation of Natural Language Search and Contextual Trace Explanation that intelligently leverages these loaded skills.</p><p>&nbsp;- **Local-First Support:** Verified compatibility with local model runners (e.g., Ollama, Llama.cpp) to ensure deterministic performance without sending data to public clouds.</p><p>&nbsp;- **UI Integration:** Enhancements to the Jaeger React UI to expose these AI capabilities and visualize the "reasoning steps" taken by the agent.</p><p>&nbsp;- **Documentation:** A complete guide for users on "How to Author Custom AI Skills for Jaeger."</p><p>- **Learning Opportunities:**</p><p>&nbsp;- **Agentic AI Architecture:** Learn to design stateful AI agents in Go that utilize "Tool Calling" and "Reasoning Loops" rather than simple text generation.</p><p>&nbsp;- **OpenTelemetry Internals:** Gain deep familiarity with the OpenTelemetry Collector architecture, as Jaeger v2 is built directly on top of it.</p><p>&nbsp;- **Cloud-Native Engineering:** Experience contributing to a graduated CNCF project, including navigating code reviews, writing design docs (RFDs), and adhering to open-source best practices.</p><p>&nbsp;- **Full-Stack Development:** Practical experience bridging a complex Go backend with a modern React frontend.</p><p><br></p>

This project aims to improve the chat experience in Jitsi Meet by introducing additional features and user interface enhancements. The goal is to make the chat more versatile, user-friendly, and interactive, thereby improving communication during video conferences. Message Reactions — Users can react to chat messages with emojis, providing quick and expressive feedback. Message Menu — A new kebab menu for each message, offering easy access to various actions. Copy Message — Allows users to quickly copy message content. Private Message — Enables users to start a private conversation directly from a group message (relocated from previous implementation). Edit Message — Will allow users to modify their own messages after sending. Delete Message — Will allow users to retract their messages.

Thanos (https://thanos.io) has its own PromQL (Prometheus (https://prometheus.io) querying language) engine. The original PromQL engine recently added support for new aggregations. We are missing support for them in the Thanos PromQL engine (https://github.com/thanos-io/promql-engine). In this project you will implement support for limitk and limit_ratio. See issue (thanos-io/promql-engine#515). This will unblock users who need this functionality. The project is interesting because you will learn how query engines are implemented, about distributed query execution. Expected Outcome: limitk, limit_ratio are supported in the Thanos PromQL engine (local & distributed modes), tests are written for them

pgmoneta is a backup / restore solution for PostgreSQL, it supports doing backups, listing all backups for a server, restoring a backup from a server, archiving a backup from a server, deleting a backup as well as retaining a backup from a server at a local level. This project aims to abstract how backups are stored in various locations such as locally and on remote machines. By the end of GSoC 2022, I would like to complete the following work: 1- Implementing a local storage engine. 2- Implementing a SSH storage engine. 3- Implementing Amazon S3 storage engine. 4- Implementing Ceph storage engine. 5- Supporting other pgmoneta-cli commands as restore, archive, delete and retain for storage engines. Supporting Ceph storage engine depends on whether implementing S3 storage engine has been finished or not.