Explore Projects

Customized SSH Authentication Free Implementation of the Cloud-COPASI for UConn users: The project proposal aims to create a customized version of Cloud-COPASI that already has a predefined HPC pool connection which will be used by all registered users of this version of Cloud-COPASI. It will also implement a quota system to prevent abuse of computing resources. This will be accomplished by using a predefined SSH connection to the facility. Instead of user holding the private key and moving the public key to the remote submit node, the server holds a database of all remote nodes and for each node it creates a separate public and private key pair. The public key will be copied to the remote node. The private key would be saved on the server. Whenever an authenticated user tries to connect to a particular submit node in the HPC facility, the private key for that node will be fetched by the server and will be used to authenticate the user against that remote node and there will be no need for the user to configure and enter any private key at all. Thus there will be just one private key for all users of a particular submit node. Server will also keep a tally of all the users that are currently using the server's private key at the moment. This will help implement a quota system to ensure that the resources are not maxed out. Over the span of 12 weeks, a customized version of cloud COPASI will be produced that will provide an easy to use interface for UConn users to submit their jobs and get results in quick time.

Verification in hardware design is a time-consuming and complex task as well as requires manual effort to update UVM testbench components (scoreboard, driver, sequencer) with constant changing DUT. This project proposes to solve this by using AI and NLP to extract key information from the provided DUT specs and updating the UVM components accordingly. This will reduce the manual effort of updating the components and optimize the process of verification. Project Deliverables are : An NLP-based parser for extracting DUT parameters Automated UVM component generation and adaptation Reinforcement learning for better verification environment

<p>The Component Development Kit as of now supports only Non UI components and lacks multiple language support. This proposal aims at upgrading the Component Development Kit to the next level. Enabling multiple language support as well as visible UI external components. Another ambitious feature this proposal offers to implement is support Background processes. Enabling more flexibility and widening the range of Apps made with App Inventor. Some minor tweaks largely requested by the user community has also been planned to be implemented during this summer. The Projects will be selected or done as per the priority of community.</p>

Current limitations: The current Back End for the Functional Annotation of Animal Genomes project (FAANG) provides users with a public rest API to access data. But it has a few limitations. First, in order to fetch data from different Elasticsearch indices or to fetch details of different documents, user has to make multiple API request calls. Second, users have to write CURL queries to work with the API which users may find complicated. Proposed solution: The main aim of creating a new backend for the Functional Annotation of Animal Genomes project (FAANG) is to make accessing and handling required data for users much easier than the current setup. In order to achieve this the following are the main tasks for the project: First, creating a Back End for Fetching Data (BE Read): To create a GraphQL Server which will make it easy to fetch the required data using advanced operations like join and aggregations by making a single API call to the Back End. Second, creating a Front End for Fetching Data (FE Read): To create a UI for selecting which data is to be fetched. Hence using a GraphQL Server, user only needs to make a single API call, and with a better UI, user wont have to worry about writing queries for fetching data. Deliverables : 1. Basic Fetching of documents (single and multiple documents of an elasticsearch index) 2. Implementing Dataloader in the GraphQL server for decreasing DB hits 3. Implementing Filter and Join functionality between elasticsearch indices for fetching data from the GraphQL server 4. Implementing Aggregation for data to be fetched from the GraphQL server 5. Implementing Frontend interfaces to make data fetching easier and reduce mistakes from the user's side

<p>The aim of this project is to decouple the current orga-server and move to API centric approach, with orga-server as the central API server &amp; open-event-frontend as the frontend.</p>

<p>The [Ecosystem Explorer](<a href="https://explorer.opentelemetry.io" rel="noopener noreferrer" target="_blank">https://explorer.opentelemetry.io</a>) helps users discover and get detailed documentation around various OpenTelemetry components. As the project expands to more ecosystems (Python, JavaScript, GenAI), information density will increase significantly, requiring patterns and approaches tailored to more than just the initial Java Agent use case. This mentorship involves conducting UX research to understand how users actually want to consume and use this information, covering: how users currently find information about components or instrumentation (LLMs, GitHub, docs, vendor sites, trial and error); what questions they are trying to answer (what telemetry will I get, how do I configure it, what changed between versions); what personas exist (app developers instrumenting code, platform engineers running collectors, SREs debugging production); how similar tools present dense technical information (npm registry, crates.io, Go pkg site, Docker Hub); and how LLMs are being used in this area and what the experience has been with them. The research will inform how we structure information, what features to prioritize, and how to present complex telemetry data in an accessible way.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>User Interviews Report: Summarized findings from 3-5 user interviews covering different user types and key tasks</li><li>Competitive Analysis Report: Findings from reviewing 2-3 similar tools (e.g., package registries, API documentation sites) on how they present component information</li><li>Information Architecture Recommendations: Proposed structure for presenting a specific type of component data (e.g., "instrumentation" or "collector components")</li><li>Wireframes/mockups (stretch goal): Visual concepts for key user flows</li></ul>

<p>PowerShell is a widely used administration tool in Windows Server workloads. This project aims at porting it to FreeBSD in order to make it easier and faster for Windows Server professionals to start working on FreeBSD server workloads and to make available yet another shell choice which is friendly for new-coming Windows users. In order to achieve that, however, porting the .NET Core SDK toolchain, including CoreCLR, CoreFX and the CLI itself, is necessary once they are vital PowerShell dependencies. As a result, FreeBSD users should have access to PowerShell, an object-oriented shell to interact with the system, and .NET Core, which can be useful for developers to build and run their applications on FreeBSD personal and server machines.</p>

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.

Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. (1) Currently jaeger-v2 components are initialized without observability clients. We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components. The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes. (2) Jaeger-v1 components can report their readiness using an internal health check API that is connected to the healthcheck endpoint on the admin port. We need to implement similar capability in Jaeger-v2. Expected Outcome: Achieve parity in observability of jaeger-v2 compared to jaeger-v1

<p>XMPP RFCs and Specifications define connection establishment over TCP, BOSH and websockets. Smack currently establishes connection between Server and Client using TCP and BOSH. BOSH suffers from high transport overhead as compared to TCP. Also various issues with long polling are suggested to have an impact upon BOSH based systems [RFC 6202 Section 2.2]. WebSocket provides an alternative to the limitation of inefficient communication between the server and the client by providing bi-directional, full-duplex, real-time client/server communications. The protocol consists of an opening handshake followed by basic message framing, layered over TCP [RFC 6455]. Adding WebSocket support to Smack will allow it to establish a continuous Client-Server connection with less overhead.</p>

<p>Mercurial has an extension called Largefiles, which allows storing large files outside of the normal history to decrease needed bandwidth for clones and pulls. Large files are stored in a central location and you fetch them only when you need them. Largefiles extension supports by design storing files in the same location as the main repository hosting server. It can be workaround by configuring a web server to redirect largefiles request to some other URL, but this solution does not provide sufficient flexibility. The Project goal is to allow user to specify remote server where large files are stored. Instead of downloading all files from the the main repository, client would download them from remote store, which could greatly decrease load from the main server. Remote store can live anywhere on the web e. g. in the cloud, so connection among clients and the store should be secure.</p>

This project focuses on making SymPy's assumptions system more robust, efficient, and reliable through a three component architectural upgrade. The first component introduces a backend solver for Equality Logic and Uninterpreted Functions (EUF) directly into the SAT engine. The second component upgrades the Linear Real Arithmetic (LRA) solver to safely handle complex domains, irrational boundary limits, and symbolic infinities (like oo) without failing while also refactoring the core ask dispatcher to resolve many recursion loops during query evaluation. Last component, the project will replace thousands of hardcoded static unit tests with dynamic, property-based tests using the Hypothesis library. By automatically generating complex mathematical trees to find hidden bugs, these enhancements will smooth out the rough edges of the assumptions module, making it a significantly faster and mathematically stronger.

A library management add-on for managing Different online-offline FreeCAD components is a utility application for FreeCAD which allows an easy and structured management of components/models available online or offline and to easily be inserted into the FreeCAD document. Its basic functionalities is to facilitate individual component from the online repository to be able to browsed, downloaded, and extended by already available local components. For a Library management system, a robust repository of data and an local storage structure is must. This is important as user need to brows through the all the existing models which are the part of the repository and download only selective models. A structured local storage will not only also allow users to easily add their own models to the local library management system, but also to the online repository open to public. For maintaining the metadata of these, a well defined storage structure is required. All this need to have an proper interface to be operable. The interface for the above will be developed as both a Graphical Interface and module for python scripting.

<p><em>The primary goal of my idea is to implement a WAF which uses Machine Learning to detect anomalies in web traffic.</em></p> <h7>The proposed idea</h7> <p>Since the Securtea is a software that is used on the server-side of an application. In order to implement a WAF we need to monitor the traffic that is being sent to the Web Server. This could be done by utilizing the Ngnix 's and Apache's reverse Proxy. Where we configure the reverse proxy to proxy pass every request to a listening server that is capable of analyzing the traffic. Once the analysis is done it can be passed back to the required server and the response is sent back to the proxy and the proxy would send it back to the client.</p> <p>The analysis part includes , ML model that has been trained with various simulation of web traffic .The simulation includes both good and bad traffic . The traffic is then feature engineered to get additional features , that help us to identify the nature of a traffic.</p>

<p>The proposal is on implementing the SCIM 2.0 compliance test suite which can be run on both the cloud and on premise by eliminating the limitations that can be seen in SCIM 1.1 compliance test suite. In the proposed test suite, it is expected to validate the supportability of a provided service provider, in terms of the SCIM 2.0 core specification and protocol specification.</p> <p>The test suite should be able to generate a detailed analysis view and comprehensive report upon providing the server’s SCIM endpoint. The report should include the test results indicating the coverage percentage of each specification and a detailed view of the results of each test including requests sent by the test suite, expected response and the server response along with the indication whether a particular test is passed or not.</p> <p>Apart from that the test suite should be run against WSO2 Identity Server to identify any gaps between the SCIM 2.0 specifications and Identity Server and provide improvements to the product.</p>

<p>Query Optimization is an active field of research in the Database Research Community, researchers have spent significant time and resources studying the state of art in query optimization and continuously improving it through different approaches. At the 2015 VLDB conference, a team led by Dr. Viktor Leis at Munich Technical University introduced a new benchmark suite for evaluating database query optimizers. The research revisited the main components in the classic query optimizer architecture using a complex, real-world data set and realistic multi-join queries.</p> <p>This project aims to obtain the above benchmark suite, obtains an end to end analysis of various components of Derby Query Optimizer, isolate each component’s contribution towards Derby query optimization and improve the components. The analysis obtained will serve as the knowledge base for Derby’s current state of art in query optimization and help in directing future efforts towards improving Derby in the long term.</p>

<h3>Project VI: Publishing Workflow in Joomla!</h3> <p>Main goal is to replace publishing states with flexible workflows. User should can create multiple states and define transitions between them with assign role acl. In the list of items on the back side should be something to perform selected transaction between defined state in item and defined in the transaction. Created component should filter states and transactions by given extension. User for each transaction could define which action of which component will invoke when the transaction is performed.</p> <h3>Milistones</h3> <ul> <li>Schema of database</li> <li>List of states</li> <li>Create, update, delete of state</li> <li>List of transactions</li> <li>Create, update, delete of transaction</li> <li>States to workflows in core components</li> <li>Role ACL to transaction</li> <li>Perform transaction</li> <li>Action invocation</li> <li>Component respect Joomla ACL</li> </ul> <p>*more in Google docs</p>

<p>Brief Explanation: In the past, Kipi-plugins provided a way to export KIPI host data to DLNA/UPNP by a plugin using HUpnp library for Qt. Since porting this tool to Qt5 will not work as HUpnp project is unmaintained and its code is not ported to Qt5. The goal of this project is to find a new way to restore this feature in digiKam core directly (not as a plugin), using a suitable solution to support UPNP/DLNA in the long term.</p> <p>Expected results:</p> <p>Review old plugin code DLNA Export. Review all required features to export digiKam contents through a DLNA server. Implement a DLNA server in digiKam core to export photo and video hosted in physical and virtual collections. The server must have the capability to be restored at each digiKam session. Implement the server configuration panel in digiKam setup. Test the new implementation with DLNA compliant devices, as smartphones, tablets, TVs. Test the new implementation under Windows and MacOS. Write unit tests and documentation.</p>

<p>The project will add the ability to sync events from OpenMeetings Calendar and iCal/CalDAV Protocol. OpenMeetings is a Web-Conferencing and collaboration software which already has a Calendar, but it does not integrate with CalDAV yet. This project aims to include the ability to use the CalDAV as a front-end feature by any user or organization to allow bidirectional access to the calendar server.</p> <p>This task will make use of the CalDAV4j, iCal, and jackrabbit-webdav libraries to implement the CalDAV client for OpenMeetings.</p> <p>This will be done in 3 stages:</p> <ul> <li>Implement client for CalDAV</li> <li>Extend openmeetings-db to store the server credentials and calendar to the database.</li> <li>Extend openmeetings-web to add read and write access to the user's CalDAV server.</li> </ul> <p>CalDAV implementation to the calendar would be one major upgrade to the current OpenMeetings Calendar, which at the moment uses a local database on the OpenMeetings Server to store the calendar data, allowing groups more flexibility in setting and viewing their respective schedules.</p>

<p>hydrus is a set of Python based tools for easier and efficient creation of Hypermedia driven REST-APIs. hydrus utilises the power of Linked Data to create a powerful REST APIs to serve data. At the moment, hydrus does allow POST operation on hydra:Collection, but new functionalities should be added to effectively update, get or delete particular members from a Collection without actually sending the whole collection in the request payload. The flagship server hydrus can only serve static data and does not provide a way to define custom server-side logic. A new feature for dynamic endpoint could be added so that a developer would be able to define logic/functions for how the incoming data is processed on the server end. A lot of improvements are possible in CRUD operations of hydrus, including setting up constraints and handling errors on the server-side depending upon how the data is stored in a Collection. The project also aims to enhance the functionality of hydrus, optimize existing codes and keep it synced with upgrades and development in hydra-python-core, hydra-python-agent, and Hydra specifications.</p>

<p>The project is to rewrite the frontend of OpenDF with ReactJS and Redux. Some UI Components have been done and others will complete through the project. After completion the Frontend will be fully component based frontend. Also testings will be done for the newly created components.</p>

The UI Toolkit serves as a component library tailored for crafting web interfaces within the Jupyter ecosystem, encompassing platforms such as Jupyter Hub, Jupyter Widgets, and Jupyter Lab. With the introduction of this toolkit, the aim is to capitalise on its capabilities to enhance UI consistency and alleviate maintenance overhead. Here's a structured plan to achieve this: 1.Use toolkit search/input for all search/inputs: filebrowser, extension manager, debugger kernel source 2.Use toolkit button for all buttons: Dialog, extension manager, notification, running tabs 3.Use toolkit tree view for all tree view: table of content, debugger variables and running tabs 4.Use toolkit for the settings editor 5.Add icon component to the toolkit 6.Use toolkit icon for LabIcon 7.Add window split component to the toolkit 8.Add tree grid component to the toolkit 9.Add dock panel to the toolkit 10.Explore switching default renderer in lumino by the toolkit: a.Menu b.Tab panel c.Dock Panel I am committed to collaborating closely with my mentor, @Frédéric Collonval, to tackle these challenges efficiently and deliver tangible results within the stipulated timeframe of the Google Summer of Code program.

The ros2_control framework uses a plugin-based system to support multiple hardware drivers at the same time. It takes care of resource constraints between different controllers and hardware components, asynchronous operation of controllers, etc. As of now, controller_manager publishes the diagnostics of itself, and for controllers and hardware components about their lifecycle state and operational statistics such as their periodicity and their execution time. However, A current limitation of the framework is that hardware components, e.g. the ros2_control hardware driver plugin for a given robot, doesn't have a good API for reporting the diagnostics of its own hardware, for instance, the state of the CAN Bus, some internal motor control board stats like temperature, error codes etc. This integration would make the ros2_control, provide complete diagnostics within its ecosystem. This project focuses on setting up an API that hardware manufacturers & driver maintainers can use to report things with minimal code changes to their existing setups. This project thus aims to add reporting capabilities to the hardware components with minimal changes. It will also aim to unify the three existing hardware interfaces into one as they currently contain a lot of similar code. Furthermore, to enhance the contribution, there will also be focus on adding contributions to exisiting widely used Hardware Interfaces with the new API so that the work is adopted with ease, and the community has better references to work off of.