Explore Projects

<p>Web Sites have evolved a lot from static mundane texts to interactive ajax based web sites and today’s Single Page Applications which provides user with a very intuitive experience. React has been one of the front-runner frameworks spearheading this more robust front ends rendering SPA frontend dramatically fast. This has been at the cost of getting down a barrage of javascript in the beginning and rendering it on the fly using the browser’s Javascript and rendering engines. This is counter intuitive to the User Experience goals of a single page application paradigm.</p> <p>A trivial solution that comes into mind is to push this workload to the server to process this Logic in the back end and send it to the server. This raises the concerns of the requirement of an Isomorphic JS backend such as NodeJS. However, with a back end that utilize Java 8 which comes packing with a much more advanced Javascript Engine - Nashorn, possibilities crop up.</p> <p>The main idea of this project wraps around finding an efficient paradigm to develop SPA’s by pre-rendering partially or whole HTML DOMs in the back end and delegating the basic DOM rendering of the static or partially static contents to the browser.</p>

Currently, in OpenYurt, the core component YurtHub—which acts as a transparent proxy between edge node system components (e.g., kubelet, CNI, CoreDNS, kube-proxy) and the Kubernetes API server—is deployed as a systemd service on each edge node. The installation is performed exclusively via the community-provided tool YurtAdm during node joining. This approach imposes a significant limitation: users must use YurtAdm to onboard nodes, making it impossible to install YurtHub on existing Kubernetes nodes that were not initially provisioned with YurtAdm. To improve flexibility and user experience, the community aims to support a label-driven, declarative installation mechanism: 1. When a specific label (e.g., openyurt.io/is-edge-worker=true) is added to a node, YurtHub should be automatically installed and started on that node. 2. Conversely, when the label is removed, YurtHub should be gracefully uninstalled and its resources cleaned up. This enhancement will enable seamless integration of OpenYurt into existing Kubernetes clusters without requiring re-onboarding of nodes. Expected Outcome: 1. Design and implement a controller/operator that watches for node labels and triggers YurtHub lifecycle operations. 2. Develop an installation/uninstallation mechanism that: a. Installs YurtHub as a systemd service. b. Ensures idempotency and handles failures gracefully. c. Cleans up all YurtHub-related files, configurations, and services

You will create an AI agent based on open-source Large Language Models (LLMs) running on the CNCF WasmEdge runtime and an MCP server. The application will tie together key components in a modern AI agent stack to create a useful application. The AI agent will ask, answer, and explain practice questions for a specific tech certification program. It enables students to study for the certificate tests more effectively. Expected Outcome: 1. Deliverable 1: create a MCP server with 2 functions a. get_random_question(): The function selects a random question from a list. It returns both the question and the answer. This function is called by the LLM when it detects that the user asked for a new practice question. b. get_question_and_answer(): The function searches an input text from the database for an corresponding question and answer. 2. Deliverable 2: create a practice question / answer database on a subject that you are most familiar with. The MCP functions will 3. Deliverable 3: Create an agent app based on the LlamaEdge framework with a 4. Workflow 1 a. The user asks a question. The LLM calls MCP function get_question_and_answer() b. The agent adds the answer to the context c. The LLM converse with the user with knowledge about the question and its answer 5. Workflow 2 The user asks for a practice question. The LLM calls MCP function get_random_question() to get the question and answer.

etcd is a distributed key-value store that serves as the backbone for Kubernetes and other cloud-native systems, storing critical configuration and state data. However, at scale, multiple applications constantly querying etcd for current state and watching for changes can overload the server and create expensive catch-up scenarios for slow subscribers. This project developed an experimental caching solution that brings Kubernetes' proven watch cache pattern to any infrastructure project without depending on the Kubernetes codebase. Core Components: (1) Watch Demultiplexer: Consolidates multiple client watch subscriptions into a single upstream etcd connection, then broadcasts events to all subscribers, reducing server load; (2) Event History Buffer: Maintains an append-only ring buffer of recent watch events, enabling lagging watchers to catch up from local history rather than reopening expensive upstream watches; (3) B-Tree State Mirror: After an initial snapshot, builds and maintains an in-memory B-Tree of current key/value state, applying watch events incrementally for fast range queries and lookups; (4) Point-in-Time Snapshots: Preserves historical B-Tree snapshots in a ring buffer, allowing exact stale reads at specific revisions without hitting etcd; (5) Resilient Control Loop: Handles initialization, upstream errors, compaction events, and automatic cache rebuilding with proper client notification.

The RISC-V movement has massive potential to unify a fragmented industry behind a single instruction set architecture (ISA). If the participants in the industry can agree to focus their efforts on a single processor architecture, rather than duplicating efforts among incompatible architectures, the entire computing ecosystem benefits. Inefficiency in critical base components of the ecosystem hampers this consolidation. There are separate efforts in documenting the RISC-V ISA, succinctly describing the semantics of the ISA in the RISC-V Sail implementation, and the numerous projects which directly serve as the base components of the software ecosystem, including assemblers, disassemblers, compilers, linkers, loaders, simulators, emulators. In summary, the tasks in this project will include: Improving the RISC-V Sail specification. (Sail language, git/GitHub) Improving the Sail parser’s JSON backend to extract more complete and accurate information. (OCaml, git/GitHub) Improving the RISC-V ISA interactive web site with new functionality and information. (Javascript, React, Carbon, or similar web frameworks, git/GitHub) Survey downstream projects which have dependencies on the RISC-V ISA. (C, C++, RISC-V assembly) Implement transformations of RISC-V ISA representation in JSON into downstream project content. (Python or similar, C, C++, RISC-V assembly) Engage with upstream projects (Sail, RISC-V Sail specification) to submit change proposals and see that they become acceptable.

<p>Currently Compliance Tester is a command line tool to check compliance status of an XMPP server. Testing servers for compliance with XMPP extensions is a very cumbersome process in which a server admin or willing user has to download the jar, run it and make a PR to the repo with the results to add it in the overview page. Through this project, I intend to automate this process and turn this project to a web service, which will provide a interface for testing servers, periodically run tests on public servers and visualise current and historic compliance status of servers, implementation of XMPP extensions across servers. Custom badges will be generated for servers from the latest test results. Periodic reports will be generated from the test results and sent to subscribers. Moreover, the collected historical data can also be analysed to recommend appropriate Jabber servers for users.</p>

<p>The primary objective of this project is to develop a GUI dashboard for the Kea DHCP server software to function as a remote monitoring and management console. This frontend web application integrates essential features from the Kea Control Agent (CA) REST API, delivering to users a mechanism for monitoring and configuring the states of remote DHCP servers.</p> <p>Server Monitoring and Management features:</p> <ul> <li>Interface with DHCPv4 and DHCPv6 servers and switch b/w server machines (CA Address)</li> <li>View server status, subnet and shared network layout with real-time utilization stats.</li> <li>Device OUI and lease statistics.</li> <li>Control server operation with local boot ops (start/stop/restart)</li> <li>Utilization threshold alerts and event reports.</li> <li>Examine server logs in real-time (local server).</li> <li>View and modify server config with change testing and updating options.</li> <li>Modify specific server params for network entities (subnet, shared n/w, host res) through editable forms.</li> </ul>

Multi-language SDK generator suite producing official client and server SDKs for Flutter, React Native, Swift, and Go.

<p>Nvim works as both a server and a client. “Nvim client” can connect to any other “Nvim server” and Nvim GUIs can show the screen of a remote “Nvim server”. But the built in Nvim TUI cannot show the screen of a remote Nvim server. The goal of this project is to bring this functionality to Neovim.</p> <p>The aim of the project can be summarized as: Whenever the user starts Nvim as</p> <p><code>nvim --connect {addr}</code></p> <p>the Nvim will connect to the Nvim server running at <code>{addr}</code>, where <code>{addr}</code> is either a <code>pipe</code> or a <code>tcp</code> address. The Nvim client instance would send input to the remote Nvim server and reflects the UI of the remote Nvim server. So the Nvim client acts like any other external GUI.</p> <p>Thus, this project makes <code>TUI</code> an RPC client. This enables us to convert <code>nvim</code> from a multi-threaded process, where <code>TUI</code> and <code>nvim server</code> ran on separate threads, to a multi-process system with <code>TUI</code> and the <code>server</code> running as separate processes and interacting with each other using the RPC API (<code>MessagePack</code>) of <code>nvim</code>.</p>

<p>IPv6 re-configuration through DHCP is a server triggered mechanism for the clients to update their IPv6 addresses and prefixes. The server behavior of sending and handling Reconfigure message is specified in RFC3315bis Internet draft. Kea-dhcpv6 server currently does not support Reconfigure messages and its associated remote key authentication protocol. The task of this project would be to extend Kea server software with the support of sending and handling of Reconfigure message in kea-dhcpv6 server as specified in RFC 3315-bis Internet Draft</p>

dubbo-rust provides basic RPC communication and service governance capability in microservice scenarios. deliverables: + protoc-gen-rust-triple: protoc plugin + service governance capability: server discovery, server registry, config server, metadata server + dubbo-rust code

Robotics Academy is a framework for learning robotics and computer vision. It consists of several exercises, where each exercise consists of exercise.py and exercise.html, the web template is currently built on HTML, Javascript, and CSS. The purpose of this project is to migrate and improve the web template by using advanced front-end technologies like React, Vue, or Angular. The technology I have chosen for the project is REACT, an open-source library providing fast and better performance. There are 26 exercises and a Home screen that are required to be migrated to REACT. Along with REACT, worldview for 2d and 3d rendering, noVNC library to create VNC client, reactstrap for styling, react-router-dom for routing, and reactAce to create an ACE editor. The deliverable for the project will be a folder containing templates for the exercise in react, repository architecture updated accordingly, and documentation.

Pgexporter provides Prometheus metrics for PostgreSQL servers which include some core metrics, as well as custom metrics provided by users. The custom metrics are SQL queries that are run by the various servers, which subsequently may have a variety of PostgreSQL versions. If a query has parts of it not supported by a particular such server, then the whole query gets rejected. This proposal aims to solve this issue by enabling users to provide alternatives of the query of a metric along with the minimum PostgreSQL version on which each alternative query’s supported. Thus, whenever a particular server will need to be queried with a custom query, then based on the PostgreSQL version of the server, the corresponding query will be sent to the server, and the response will be formatted in the form of Prometheus metrics. This will greatly benefit both the users, as well as developers, to provide an out-of-the-box solution and would neither require the updation of codebases to cater to new PostgreSQL major version releases, nor would require the users to adapt to that change.

<p>The goal of this project is to write a replacement for the now removed ffserver component. It should meet the criteria proposed for the work on ffserver while there was still discussion about it. The result should be a multi-protocol streaming server that only uses the public API.</p>

This proposal outlines a comprehensive plan to implement a system that enables end-users to verify the integrity of their game files against reference checksums. The system will be composed of a server component for storing and comparing checksums and an extension within ScummVM for computing and submitting these checksums.

<p>Build an inventory of the features present in the legacy UI that need to be moved to OWAs Replace existing JSP UI with OWA based on React Components then delete the JSP pages and build missing web service end-points which may not exist.</p>

<p>Webiu is a “generalized website builder” which magnificently eases the essential process of getting a website up and running easily. The project provides almost all of the different sections required by a normal website as different reusable components. This project proposal aims at adding and implementing new features and functionalities into the current project to make it more reusable and accessible and further ease the process of building a website. Creating a logo, improving current components functionally, developing new components, creating an NPM package for Webiu, documenting the components using Storybook are some of the works (but not limited to) proposed. The proposal when implemented will functionally improve the current project, increase the range of the project and make the components accessible to other developers to incorporate them for developing websites.</p>

The architecture of the GHC compiler in its current state is anti-modular. Designed with GHC-the-program as the sole consumer in mind, it is very difficult for newer tooling to reuse its components. These problems extend to the inclusion of new backends such that implementations for various target platforms forked GHC frequently. The first step to improving the current design is the isolation of the different components and separation the codebase in layers for different purposes, described in the classic book "Domain Driven Design". This is already partly done, and in this project I join the existing effort by working on the next remaining subsystem: GHC's Core pipeline. In order to achieve my goal, I will proceed by using an incremental bottom-up approach: Starting at the bottom of the module hierarchy, I will push references to upper layers module-by-module up in the callstack until they are completely removed from each component. For the entry points of each in-scope component, I will then provide component-specific configuration types and corresponding initialization functions. The in-scope components are specific configurable tasks of the optimizer, and the optimizer as a whole. With this work completed, there will be significantly less references to the ubiquitous global states used throughout the whole compiler, namely the DynFlags and the HscEnv type, and significantly fewer imports of modules from upper layers, e.g. the driver.

<p>Project: Migrating the 'Koko' image gallery application's UI components to Kirigami.</p> <p>Brief Explanation: The current version of Koko uses the QtQuickControls components that use QML for internal event handling. However, kirigami uses QtQuickControls2 components that provide better internal event handling(done through c++). The project will focus:</p> <ul> <li>Designing basic components required for Koko through kirigami, C++ and QtQuickControls2.</li> <li>Using the components in the application itself.</li> <li>Adding Tap-and-hold gestures.[Optional]</li> </ul> <p>Expected Results: Have a proper functioning mobile-friendly user interface for Koko on the top of kirigami.</p> <p>Knowledge Prerequisite: QML, Qt5 and C++.</p>

New Frontend Framework for Simulator UI The project focuses on replacing JqueryUI with a modern frontend framework. I have divided the coding time period into 5 Parts - 1. Decoupling the Simulator 2. Dividing into Components 3. Sate Management 4. Refactoring CSS 5. Internationalization using vue-banana-i18n I will start by decoupling the Simulator UI from the backend followed by restructuring the folder structure. Dividing the Simulator UI into small Components, replace DOM mutations with strings by conditionally rendered components. Managing the states of different components and using various powerful features of the frontend framework like Lifecycle hooks. Refactoring the styles into their respective components. A lot of work for Localization of Simulator has already been done, so integrating it with the new frontend framework.

Integrate a new user experience into Meshery: a cloud native design configurator. This project involves presentation of Kuberenetes core resources and any custom resource (CRD) as a configurable component in a React-based user interface in which users design (in great detail) and deploy their cloud native infrastructure. Interns will familiarize with concepts of content lifecycle management.

ROOT is a framework for data processing, born at CERN, at the heart of the research on high-energy, molecular and laser physics, as well as in astronomy. ROOT has plenty of built-in components. Because of a variety of features, ROOT is a very large software which takes a very long time to compile. Currently ROOT compiles all of the components available within the source code distribution. The goal of the project is to speed up the compilation process by letting users specify which components of the ROOT will be needed. This can be done by converting ROOT’s CMake configuration into a set of “CMake External Projects” (superbuilds). Superbuilds can remove all of this cruft from the project’s source repository, and enable you to more directly use the upstream project’s build system as an independently built software component. It is basically a simple package manager that you make consistently work across your target build platforms, and if your target platforms have a common package manager you might consider using that instead. Also, during the configuration process it could be possible to identify if ROOT is already installed in the destination folder, the components which are already installed and offer an option to skip their compilation and use these already installed components for current compilation. We are not going to change the build system of ROOT, but to optimize it and offer users an option to select only the parts of the ROOT to be built. Partial builds for ROOT can allow the creation of “edition” builds if necessary.

Libafl is a library written in Rust that provides components to build fuzzers. A newcomer might feel confused when creating a fuzzer because that requires some knowledge of what each component does and how they can be used together. Without prior experience, going through the repository and trying to understand these features on your own is not a trivial task. To make Libafl more beginner-friendly, as well as didactic, this project proposes the implementation of a Fuzzer Template Generator. The generator will guide the user through the components, explain their functionalities and utilization, and output snippets of that component's Rust code, so the user may apply it to their fuzzer implementation. Therefore, this project aims to: 1. Implement a wizard, to show options and take the user's decisions, 2. Add a progressive flow chart generation, to help keep visual track, 3. Output Rust code for each component selected.