🎨 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?
• How can I help?
• How should I behave here?
• How do I report security concerns?
• What third-party dependencies are used?

✅ 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:

• Create a common attribute for ignoring members.
• 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:

[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:

[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:

[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<string, string> 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.