Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/tacosontitan/pasper
A lightweight, provider agnostic, serialization proxy designed to simplify serialization definitions.
https://github.com/tacosontitan/pasper
agnostic binary dotnet json provider proxy serialization toml xml yaml
Last synced: 14 days ago
JSON representation
A lightweight, provider agnostic, serialization proxy designed to simplify serialization definitions.
- Host: GitHub
- URL: https://github.com/tacosontitan/pasper
- Owner: tacosontitan
- License: apache-2.0
- Created: 2023-04-10T22:35:00.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2024-11-26T03:26:44.000Z (about 1 month ago)
- Last Synced: 2024-11-26T04:24:58.160Z (about 1 month ago)
- Topics: agnostic, binary, dotnet, json, provider, proxy, serialization, toml, xml, yaml
- Language: C#
- Homepage:
- Size: 120 KB
- Stars: 2
- Watchers: 1
- Forks: 0
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- Funding: .github/FUNDING.yml
- License: LICENSE
- Code of conduct: CODE_OF_CONDUCT.md
- Security: SECURITY.md
Awesome Lists containing this project
README
# 🎨 Pasper
Pasper is a proxy for serialization services that allows consumers to simplify their attribute requirements by using a single attribute to describe how a type should be serialized, or ignored.
The name is a combination of the acronym PASP (Provider Agnostic Serialization Proxy) and provider to create a unique name that is easy to remember.
## 💁♀️ Getting Started
Get started by reviewing the answers to the following questions:
- [How do I navigate the codebase with confidence?](http://pasper.tacosontitan.com)
- [How can I help?](./CONTRIBUTING.md)
- [How should I behave here?](./CODE_OF_CONDUCT.md)
- [How do I report security concerns?](./SECURITY.md)
- [What third-party dependencies are used?](./NOTICES.md)
### ✅ Small changes, continuously integrated
Pasper employs workflows for continuous integration to ensure the repository is held to industry standards; here's the current state of those workflows:
### 💎 A few more gems
We believe in keeping the community informed, so here's a few more tidbits of information to satisfy some additional curiosities:
## 🛣️ Roadmap
The following is a list of features that are planned for the future:
- [x] Create a common attribute for ignoring members.
- [x] Create a common attribute for serializing members.
- [ ] Create a way to transform member names based on the format.
- [ ] Add support for XML.
- [ ] Add support for XML elements.
- [ ] Add support for XML attributes.
- [ ] Add support for XML arrays.
- [ ] Add support for JSON.
- [ ] Add support for YAML.
- [ ] Add support for TOML.
Each format Pasper provides support for will be contained in its own assembly to allow consumers to only include the formats they need. The naming convention for these assemblies will be `Pasper.{Format}`, for example:
- `Pasper.Json`
- `Pasper.Yaml`
This will allow consumers to easily identify the format they're after, and only include the assemblies they need.
### 🆘 What problem does Pasper aim to solve
Most serialization providers define their own attributes for defining how members should be serialized or ignored. This can lead to a lot of clutter in your codebase, especially if you're using multiple providers:
```csharp
[XmlElement("Id")]
[JsonProperty("id")]
[YamlMember(Alias = "id")]
public int Id { get; set; }
```
Each provider does it a little bit differently, and each provider has its own set of attributes. This can lead to a lot of code duplication, and a lot of confusion when you're trying to figure out how to serialize a type. The idea behind Pasper is to simplify this:
```csharp
[SerializedMember(nameof(Id))]
public int Id { get; set; }
```
This is a lot cleaner, and a lot easier to understand. It also allows you to easily switch providers without having to change your codebase. This is especially useful if you're using multiple providers, and you want to switch from one to another.
### 🏆 What is the biggest obstacle currently
XML supports many different attributes such as `XmlElement` and `XmlAttribute`. This will need to be taken into consideration while designing the common interface as most other formats aren't as flexible. This is likely to be the most challenging aspect of this project, and will require a lot of thought and consideration.
### 🤔 Something else to think about
Currently, consumers have complete control over how their types are serialized with each specific provider. This means that Pasper will have to provide a way to support this level of control, while still providing a simplified way to serialize types. One way we might approach this is by preferring the provider defined attribute over the Pasper defined attribute. This would allow consumers to use the provider defined attribute to override the Pasper defined attribute, while still providing a simplified way to serialize types. This is likely the most concise way to provide this level of control, but it's not likely to be the only way, so we're open for ideas.
Imagine the following scenario:
```csharp
[XmlElement("ID")]
[SerializedMember("id")]
public int Id { get; set; }
```
In this use-case, the consumer is using the `XmlElement` attribute to define how the `Id` property should be serialized. Pasper should respect this, and use the `XmlElement` attribute to serialize the property, rather than the `SerializedMember` attribute. However, for all other providers, Pasper should use the `SerializedMember` attribute to serialize the property.
#### 🔤 How should we handle casing
Ideally, we just take the input and use that as the desired output, regardless of format. However, we should consider transformation of the output based on the format. This can easily be achieved by using an interface, `Func` or many other methods that provide the consumer with the ability to transform the output.
### ✨ Potential Features
The following is a list of features that are being considered for the future:
- [ ] Add support for INI.
- [ ] Add support for HOCON.