Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Optional text serialization (JSON, YAML, whatever) #110

Open
BreyerW opened this issue Sep 22, 2015 · 3 comments
Open

Comments

@BreyerW
Copy link

BreyerW commented Sep 22, 2015

Do you have any plans for introduction optional serializing to text, human readable format? In theory i could just integrate existing solution with Migrant but this potentially break feature compatibility (version tolerance, session persistence (?), delegate not serialized, etc.)

Use case: I have at least one situation when this is helpful: versioning in editor app.Plain (without extesions) github and other versioning solution very often dont like binary format so editors offer serializing to text or to binary. Real world example: Unity3d.

Side note: did you hear about Capn Proto, Flat buffer? they are relatively new approach in serializing, removing encoding steps, offer zero allocation, zero copy, insane speed. I m stick with migrant because they are limited to struct (what i actually think is a bit too strict for my project) for zero allocation and partially .Net version have slow development. Maybe you could develop your own solution with migrant as option or contribute to existing solution (capn proto C# version is developed by marc gravell) if u find this approach as useful.

Thanks in advance for reading my request

@PiotrZierhoffer
Copy link
Member

PiotrZierhoffer commented Sep 23, 2015

Hi

Text-based serialization is in fact in our scope of interest. It would require some work but is certainly doable. Since you have sparked a discussion, we might think about doing it but I cannot tell you when exactly.

As for Capn Proto - yes, we know this project. It is interesting but focuses on different aspects than we do. With Migrant you can serialize/deserialize your own data, in most cases with zero additional overhead to describe the data model etc., even for complicated scenarios with delegates and whatnot. Whereas, Capn Proto requires a schema (a precompiled one, in case of .net).
Capn Proto actually works with "already serialized" data, which is fun and definitely has it's uses, but is also very restrictive. It's a matter of choice between highest speed of Capn Proto and flexibility of Migrant (with quite good performance as well ;-)).

Thanks for suggestions, if you have any concerns using Migrant do not hesitate to email us.

@BreyerW
Copy link
Author

BreyerW commented Sep 23, 2015

well there my thoughts on current human-readable formats:

most used: xml, json, yaml, ini and sometime cvs

xml out of the question IMO: slow, fat and not so human-readable when file become big format with no big advantages: widely used thus a lot tools/library to interact with xml but this feature have json as well

cvs i think not worth effort probably least used format but better than xml in term of performance/readability, very, very tiny syntax (for serializing this might be disadvantage)

ini in theory could be used but they are supposed to serve as configuration or initialization file so i dont recommend this

json: tiny syntax but often used for serializing so battle-tested, widely used even support web (this may be big advantage to some developers) Disadvantages? very minor and appear only when compared to yaml (less features like syntax for 'reference field' so you can avoid copying indentical field but with different name/key across file (might be extended to across project by yourself but that isnt 'official' ^^), bit fattier syntax thus potentially a bit bigger file)

Yaml: nicest and most lighweight syntax (thus smaller file) in basic implementation, widely used (but not as much as xml/json), a lot features. disadvantages? no direct web support, a lot weird syntax in advanced implementation for these features mentioned ealier (can be fixed by yourself with setting constraint what use and what abandon for serializer)

conslusion? my vote go for yaml or json

BTW if file needed to be even smaller with reasonable performance penalty then LZ4 compression as optional process seems best option for performance/compression ratio

@yallie
Copy link

yallie commented Oct 26, 2016

Any news on this subject?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants