Explore Projects

<p>pygeoapi is a python server implementation of OGC RESTful API standards. The current implementation of OGC Features API in pygeoapi supports only read operations. I propose to implement simple transactions (create, replace, update, delete) in pygeoapi OGC Features API in accordance with <code>OGC API - Features - Part 4: Simple Transactions</code> proposal. This involves the following:</p> <ul> <li>Create a sample openapi specification doc in accordance with <a href="https://github.com/opengeospatial/ogcapi-features/tree/master/extensions/transactions" target="_blank">Simple Transactions Proposal</a></li> <li>Generate the proposed openapi doc from pygeoapi config</li> <li>Define REST endpoints for simple transactions (POST, PUT, PATCH, DELETE) in Flask and Starlette</li> <li>Update pygeoapi core API to handle feature transactions</li> <li>Implement simple transactions in schemaless data providers - GeoJSON, CSV</li> <li>Implement simple transactions in schemaful data providers - PostgreSQL, SQLite</li> </ul>

This proposal aims to upgrade and expand existing open-source tutorials and examples to support the new unified Gemini SDKs for JavaScript/TypeScript and Python. My approach involves three key components: (i) Cookbook Migration: Migrate existing Python examples in the Gemini Cookbook to idiomatic JavaScript/TypeScript. I will ensure the code follows best practices in both languages and is thoroughly documented like the already existing cookbook examples. (ii) New Tutorials & End-to-End Examples: Develop fresh, comprehensive tutorials demonstrating a variety of Gemini use cases. Examples include building a chatbot, creating a text summarization tool, and generating images from text prompts. Each tutorial will include step-by-step instructions, code samples, and in-depth explanations of underlying Gemini concepts. Deliverables include: - A set of migrated and newly developed code examples in both Python and JavaScript/TypeScript. - Comprehensive, user-friendly tutorials and documentation that clearly explain the code and underlying concepts. - Updated examples for existing open-source libraries utilizing the Gemini SDK, with clear migration guides.

Agentic AI is commonly used to predict and resolve problems before they occur, requiring access to data in near real-time. However, traditional patterns for reacting to data changes come with major disadvantages, exacerbating the challenge of building resilient, near real-time distributed systems. These patterns include polling, which is simple to implement but has a fundamental tradeoff between minimizing load on data sources and minimizing data staleness. Change data capture (CDC) avoids the aforementioned issues, but requires teams to build and maintain custom infrastructure. Using Drasi’s ability to track derived entities (via Continuous Queries) and Dapr Agents’ out-of-the-box durability for agents and agentic workflows, this proposed integration would help developers build scalable, event-driven AI systems in products and internal platforms. To accomplish this, Drasi would need a new ”proxy” service that routes events to multiple publish-subscribe (pub/sub) topics. Dapr workflows and agents would consume from these topics via workflow decorator functions and agent middleware, supporting Drasi and providing the groundwork to integrate other backends.

Designing an open wallet based on the DIDMan specification requires consideration of several key components. These include authentication, DID management, cryptographic operations, interoperability, user interface, security, and backup and recovery. The OpenWallet must have a secure authentication mechanism and support the DIDMan specification to manage DIDs, their associated keys, and metadata. The wallet must also support cryptographic operations, have a user-friendly interface, ensure security, and allow for backup and recovery. By adhering to the DIDMan specification, the wallet can ensure interoperability with other compliant systems and promote the adoption of decentralized identity technologies. Expected Outcome - The expected outcomes of designing and spec-ing an OpenWallet based on the DIDMan specification include developing a deep understanding of decentralized identity systems, gaining practical experience in implementation and cryptography, and prioritizing security and user experience. - Additionally, students can expect to learn about interoperability, open-source contribution, technical documentation, and real-world applications. - By achieving these outcomes, students will be equipped with the skills and knowledge needed to make meaningful contributions to the growing field of decentralized identity technologies.

While Open Library excels at patron aquisition, it struggles with retaining the patrons- this happens due to a break in flow as post sign up patrons are met with an empty dashboard and lack of personalization. Without clear guidance, patrons struggle to find 'What to do next?' and drop off without engaging with the library or features such as reading lists and social connections. This project aims to bridge that very gap between 15 million patrons and 40 million works by introducing a progressive onboarding flow and a highly personalized dashboard for its patrons. By capturing user preference on sign up, we can personalize their dashboard ridding of the empty experience and providing clear Next steps, along with redesign of the dashboard to emphasize the high value features. Deliverables: Progressive Onboarding Flow (A 3-part form that captures and stores broad patron taste, specific book taste and yearly reading goal), Personalized Dashboard (Overhaul of the present 'My Books' page to priortize high-value features and addition of the 'Next reads' system), and the Recommendation Engine that powers the 'Next Reads' components using existing solr infrastructure.

This project aims to enhance the existing appointments calendar in OpenMRS by transforming it into a more interactive, flexible, and user-friendly scheduling system. The current implementation provides only a basic monthly view with limited details, which is insufficient for real-world clinical workflows. The proposed solution introduces multi-view support (monthly, weekly, daily), enabling users to visualize schedules at different levels of detail. It will display detailed appointment information such as patient names, time slots, and statuses directly within the calendar. Additionally, navigation-based interactions will be replaced with modal-based views to preserve user context and improve usability. The project also includes support for multiple calendar systems (Gregorian, Islamic, Ethiopic, Persian) to ensure global adaptability. The implementation will follow a modular architecture using React microfrontends, OpenMRS REST APIs, and optimized data-fetching strategies. Deliverables include: Multi-view calendar (monthly, weekly, daily) Detailed appointment rendering Modal-based interaction system Multi-calendar system support Performance optimizations and testing

<p>Think back to the first website you built. Most developers start by creating a series of pages contained within individual HTML files. Each will call in assets such as images, CSS and perhaps a sprinkling of JavaScript. You possibly launched these files directly from the file system without a web server. Life was simple.</p> <pre><code>Difficulties arise as your site becomes larger and more complex. Consider navigation: it may be similar in every file, but adding a new page requires updates to every other. Even references to CSS and images can become awkward as folder structures evolve. </code></pre> <p>Consider collaborations: coordinating continuous integration from multiple sources or departments, needing the liberty to independently modify their portion of a site.</p> <pre><code>I propose the use of HUGO – a Static Site Generator. [4] An SSG is a compromise between using a hand-coded static site and a full CMS, while retaining the benefits of both. In essence, you generate a static HTML-only website using CMS-like concepts such as templates. The content can them be extracted from Markdown files. </code></pre>

This project aims to significantly enhance Mesa-Frames by building efficient and scalable data collection tools for large-scale agent-based simulations. The core focus is on developing a flexible framework that allows researchers to analyze simulation data with greater precision and lower overhead. One of the main components, the Stats Collection, will enable users to define exactly which statistics they want to track—such as mean, max, or count—helping reduce both memory usage and computation time. Another key feature is the Event Driven Collection, which records data only when predefined conditions are met. This ensures researchers capture meaningful insights while avoiding unnecessary logging and storage. To support even larger simulations, the project will also include integration with external storage systems like PostgreSQL and S3, allowing collected data to be streamed directly to disk or the cloud. In addition to these core improvements, the project will focus on performance optimization through lazy execution with Polars and better vectorization. Clear, modular documentation and a focus on usability will ensure Mesa-Frames remains an accessible and powerful tool.

Meshery's MeshSync component acts as the real-time discovery engine, maintaining an up-to-date snapshot of all managed infrastructure. Currently, mapping the complex relationships between these resources (e.g., a Service selecting Pods which are mounted to PVCs) relies on relational or in-memory lookups that can become inefficient at scale. This project involves integrating a dedicated graph database (or an embedded graph processing library) into Meshery's architecture. The goal is to ingest discovered Kubernetes resources as "nodes" and their associations (OwnerReferences, Label Selectors, Annotations) as "edges." This shift will enable highly efficient traversal and querying of infrastructure data, powering more advanced capabilities like topology visualization, impact analysis, and dependency mapping. Expected Outcome: 1. Fully-functional datastores of discovered cluster data into a graph structure. 2. Benchmarks demonstrating improved performance for complex relationship queries compared to the existing relational implementation. 3. Successful rendering of the infrastructure topology in Meshery UI using data fetched from the new graph backend. 4. Comprehensive documentation covering the new graph schema and query patterns.

This project focuses on systematically expanding regression test coverage for the ESP codebase by targeting high-risk, untested logic paths rather than merely increasing overall coverage percentage. Through detailed codebase exploration, critical gaps have been identified in components such as lottery assignment logic, class registration flows, and mailman integrations. These areas involve complex logic, invariants, and edge cases that currently lack sufficient test coverage and pose a high risk of silent regressions. The project introduces invariant-based testing for the lottery system to ensure correctness properties such as no conflicts, no overcapacity, and valid grade constraints across arbitrary inputs. Additionally, integration tests will be implemented for mailman functionality using mocking to validate subprocess interactions without external dependencies. A reusable testing infrastructure will be developed to support scalable regression testing, along with targeted performance checks to detect potential degradations in critical views. The outcome will be a robust regression testing framework that transforms fragile, untested paths into enforceable guarantees, significantly improving system reliability and maintainability.

This project extends Apache Airavata to support interactive development sessions on HPC clusters by integrating linkspan as a managed on-node agent. It addresses the gap by bringing interactive sessions under Airavata's existing framework for authentication, resource management, experiment tracking, and data movement. The proposed solution adds an Airavata mode to CS-Bridge in which users authenticate through Keycloak, discover resources through Airavata, and launch linkspan sessions as Airavata-managed jobs. Each session will be tracked as a first-class Airavata experiment with lifecycle state and recoverable metadata. On the backend, linkspan will be registered as an Airavata application with per-resource deployment descriptors, server-side workflow YAML generation, and an orchestration path for environment setup, job submission, and monitoring. The main deliverables are linkspan application registration in Airavata, interactive-session experiment tracking, new REST endpoints for session management, two minimal linkspan workflow actions for status and VFS reporting, Airavata mode in CS-Bridge, overlay-aware data movement integration, and an end-to-end tested and documented demonstration of the complete workflow.

This proposal outlines the development of create-webpack-app, a webpack cli tool designed to streamline project setup for web development. Leveraging the power of Webpack, create-webpack-app will provide a user-friendly interface for selecting frameworks like React, Vue, or Svelte. Users can then generate a complete project structure pre-populated with essential files, configurations, and a tailored Webpack configuration for both development and production builds. The planned 12-week development utilizes Plop.js to create reusable templates, ensuring flexibility and customization. A core base template will be established, containing essential project files like package.json, README.md, and a foundational webpack.config.js. This will be complemented by framework-specific templates pre-filled with boilerplate code relevant to the chosen framework. Additionally, comprehensive user documentation will be created, guiding users through installation, usage, and framework-specific considerations. By prioritizing a lightweight and customizable approach, this proposal lays the groundwork for future enhancements, including broader framework support and potential community contributions.

<p>AnalySim is a data sharing platform similar to GitHub, but specialized for scientific projects. It seeks to simplify the analysis and visualization of datasets. AnalySim is designed to promote collaborations and to improve existing datasets through features like forking or cloning, features specialized to allow users to start new projects, collaborations or join existing teams or projects.</p> <p>First feature I would like to add to AnalySim is forking projects, which will help collaboration between researchers. One can fork someone else’s project and improve upon it by adding more data or improving analysis. Second feature I'm interested in is adding a new design template. Finally, I want to improve the existing documentation. If there's extra time, I would like to work on adding a component that allows for CSV file viewing.</p> <p>This project offers me a great opportunity to practice my technical skills of programming the web based technologies I learned in my classes. Specifically, I have experience in working with Angular, web development and web design. I aim at starting a career in software development where I want to put to practice the skills learned during this project.</p>

The CrashDragon project aims to enhance its functionality and user experience through a three-fold approach for Google Summer of Code 2024. The project will begin with a thorough review of the existing codebase to identify areas for improvement. This will involve analyzing the current architecture, identifying bottlenecks, and proposing solutions for optimization. Additionally, I will work on enhancing the API in Go to ensure smoother integration with the frontend and better performance overall. One of the primary objectives is to optimize the backend infrastructure to enhance the overall performance of the service. This will involve optimizing SQL queries, refactoring code for better efficiency, and implementing best practices to improve scalability and reliability. Furthermore, I will focus on incorporating unit tests to ensure the robustness and maintainability of the backend codebase. A new frontend will be developed using Vue.js to provide an intuitive and responsive interface. This will involve designing and implementing user interfaces for various functionalities and integrating frontend components with the backend API. By accomplishing these tasks, the CrashDragon project aims to deliver a more efficient, scalable, and user-friendly platform for managing crash reports.

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.

Rucio has proven its potential to be used for providing functionality to scientific collaborations to organize, manage, monitor, and access their distributed data and dataflows across heterogeneous infrastructures. What it needs is a revamped user-friendly UI. This will not only encourage existing users to get a feel of how Rucio continues to grow and reach new milestones, but also increase the adoption of the Rucio WebUI in general. The desired outcomes of my stint would not only involve a complete revamp of the existing UI by building a UI library of our own but also presenting users with a new & intuitive dashboard, keeping the core functionality of Rucio in mind. Rucio also supports multiple types of users and their specific workflows. The first task would involve migrating the WEBUI to a pure REST’ful architecture would require identifying and implementing new REST endpoints on the Rucio Server and developing a dynamic cross-platform ReactJS application capable of consuming the REST API directly. The second task is to improve the overall user experience for different ‌users. The new dashboard would allow users to get a quick overview of relevant activity and provide quick access to frequently used functionalities.

<p>Currently, FreeCAD's IPython and Jupyter Notebook integration can only provide visualization by running the entire FreeCAD GUI alongside the notebook. Besides not being elegant it brings many problems with it, like not being able to save the visualizations inside the notebook for sharing or bringing visual complexity of the entire GUI into the view instead of just displaying the 3D model. It is therefore important to find a way to visualize FreeCAD's 3D scene in the IPython display system as supported by Jupyter Notebook.</p> <p>Tackling the open issue “IPython / Jupyter support” I aim to implement a IPython compatible visualization of FreeCAD’s 3D Open Inventor scene graph. To achieve this I intend to choose a suitable JavaScript library able to render a 3D scene graph and to implement a mapping between it and the Open Inventor scene graph. After this as a byproduct I want to implement a better WebGL export based on the scene graph instead of document objects as currently found in FreeCAD. For this I can reuse and integrate the scene graph mapping component. Lastly I want to document the results in the Wiki and create an example Jupyter notebook.</p>

<p>THE PROBLEM - Many universities do not have a place online for student-student and student-faculty interactions. Some universities do post results, notices etc. on their websites, but it's not easily accessible, and there is no way to notify the students when these uploads are done. Interaction amongst various student bodies, clubs etc. are done through Facebook/ Google groups, which is very inefficient. There is a need for a common platform that can incorporate these things</p> <p>The idea is to develop a Free &amp; Open source Web application for Universities. Any university should be able to easily deploy this web app on their servers. The platform will provide the following features</p> <p>Discussion Forums : A place for students and professors to have discussions.</p> <p>News : A way for the administration to push relevant news to the students</p> <p>Events: A way for both Faculty and the students to post information about events happening around the campus</p> <p>Academic notices: These includes exam schedule, time tables and results.</p> <p>Recruitment Drives: A place where students get to see the placements and internship offers, their eligibility criteria and also a way to apply to them by submitting their resumes.</p>

Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production, ref. https://principlesofchaos.org/, i.e. to induce errors on a system and see how it behaves. eBPF can be used to induce such errors on a system, it can change the return value of a kernel function, drop or modify network packets, etc. The goal of this mentorship is to implement a set of gadgets for Inspektor Gadget that helps causing system chaos. These are some ideas of the gadgets that should be implemented: - DNS: Drop/modify/add latency DNS requests and/or responses based on - The container or process performing it - The target URL - The DNS server - TCP/UDP: Drop network packets based on - Destination / Source IPs - Originating or destination pod or process - Simulate system call failures based on - Container or process performing the syscall - Syscall The gadgets should expose metrics with the number of times it induced failures, and possibly also provide notifications when those errors were induced. Expected Outcome: A set of gadgets with the above functionality should be implemented and merged on the upstream Inspektor Gadget repository. Those gadgets should include documentation and tests.

This proposal outlines the development of an innovative dashboard utilizing the Stingray library for X-ray astronomy analysis. The Quicklook Dashboard aims to facilitate the exploration of astronomical data by providing interactive tools for the visualization of light curves, periodograms, spectral colors etc. This project would make it much simpler for astronomers to focus on the problem at hand and reading the results of the data analysis techniques (of Stingray) and not go on to input one command after another. It would reduce the time invested in making the analysis work and even who are novice to command line tools to gain the benefits of Stingray. The proposed solution involves creating a web-based dashboard that streamlines the process of data visualization and analysis. The dashboard will have predefined (parameter can be edited by users) functions that users can choose to analyse the data and get the required plots in the dashboard itself. The aim is also to educate novice users/ UG-PG students to get to know about how the analysis is being done. Technologies used are: python, flask, bokeh, holoviz, HTML/TailwindCSS, vanillaJS/React.JS If time permits, the project is open to make it the start for an interactive analysis interface.

<p>During pre-dump in CRIU, the memory pages of target process are stored in pipe-pages, until the content is not flushed to disk image or page-server. Primary issue is bloat of irreclaimable memory due to pipe-pages. Pipe buffers are pinned in memory making them non swappable. Pipes have maximum size restriction, so there could be many pipes which results in memory pressure during pre-dump process. Replacing pipe-pages with userspace supplied buffer from CRIU will alleviate this memory pressure. Since, the buffer pages can be swapped out.</p> <p>Another issue is duration for which pre-dump algorithm freezes the target task. Use case like live migration expects smallest possible freezing glitch. So, objective is to reduce this freeze time during pre-dump.</p> <p>To achieve both of these objectives, we use process_vm_readv system call with a set of VMA-list gathered by freezing target task for minimal amount of time. There are challenges in handling memory areas with this approach, like race conditions resulting in false reads. Development of graceful solution for these challenges is objective of this project.</p>

The Folksonomy Engine does not support intuitive property suggestions and reusable web components. In order to enhance usability and scalability, the system requires improved property suggestion mechanisms, more effective handling of nested values, and an easier-to-use interface for data contribution and analysis.\n \n To address the challenges in data contribution, consistency, and exploration, the project will develop new API features and create a reusable web interface. The proposed solution includes developing new API features and a reusable web interface. The main goal is to get as many contributors as possible to use this, making it easy and accessible for everyone to contribute.\n \n New API Features:\n - Suggestions based on popularity and categories\n - Adding User roles\n - Improved handling of nested property values\n - Adding moderation for bulk property, value management\n - Tools for exploring and merging values\n \n Improved Reusable JavaScript-based Web Interface:\n - For display and editing of data\n - Integrating folksonomy-editor to main project\n - Potential formalization of property definitions

<p>ROS path planners such as MoveIt! and Descartes are good at finding feasible robot paths that avoid obstacles and optimize motion. In some applications, adjustments to nominal paths must be made based on sensor feedback or operator input. The issues were raised at ROSCON 2015 . The specific application driving this need is robotic assembly using end-effector force feedback, where parts such as computer board components need placement in holes or sockets with tight clearances, and the object locations may vary considerably with a need to locate them using vision systems. Achieving reactive and adaptive path planning may require extensions to several parts of ROS and ROS-Industrial, including the MoveIt! or Descartes path planners, the ROS control layer, or the Simple Message protocol to hardware robot controllers. Development can take place without actual force sensors or cameras, using simulated sources of the high-level outputs of these sensors in terms of small adjustments that affect the trajectories. The key software objective is to put in place a method to adjust trajectories after they have been nominally planned, rather than focusing on sensor processing.</p>