Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
YAML? #4
YAML? #4
Comments
|
We are not going to implement a lot of formats "out of the box", to keep runtime library small and easy-to-use. Instead, we try to encourage our users to write their own libraries for supporting different formats and build diverse ecosystem, because with serialization framework it become much easier. You can look at example project for JVM to find out how to write serializer which fits your needs (docs coming soon). If you publish a library which provides popular format for this framework, we'll include it in readme. Regarding your second question: this serialization is reflection-less, so its main target are platforms on which Java Reflection API is unavailable or not desirable (Android, Kotlin/JS, Kotlin/Native). However, even on classic JVM targets you can obtain a huge performance improvement. |
|
Thanks. Looking forward to the docs. |
* add ByteString serialization logic and tests (Kotlin#2) * fix JS compilation error * Moves ByteString to the CBOR package (Kotlin#3) * moves ByteString type to the CBOR format package and creates CBOR specific interfaces and abstract classes that extend the common Encoding/Decoding interfaces and classes. * code clean up * Abstract StructureKind BYTE_STRING:to VALUE_TYPE (Kotlin#4) (Kotlin#4) * Use @ByteString annotation to toggle encoding/decoding of byte strings This is a continuation of the Kotlin#846 effort, whereas introducing a new `SerialKind` was discouraged: Kotlin#846 (comment) Instead, a dedicated annotation (`@ByteString`) is used to differentiate `ByteArray` encoding/decoding between type 2 and type 4 (details re: [Major types] are listed in RFC 7049). [Major types]: https://tools.ietf.org/html/rfc7049#section-2.1 * Add basic documentation re: @ByteString annotation * Unify String and ByteString implementations * Minor documentation updates * Fix decode indefinite test to use indefinite byte string * Add missing comma in KDoc * Clean up debugging * Use @ByteString only for ByteArray * Only use @ByteString for deserialization as well * Micro optimization: short-circuit on boolean before object equality check * Add link to cbor_byte_string.md document from general documentation * CBOR additional information in hex notation * Add comment stating that @ByteString only effects `ByteArray` Co-authored-by: Christopher Corea <christopherc@juul.com> Co-authored-by: Pavel Vasin <pavel@vasin.nl>
Any plans for that?
Also I'm still trying to figure out why I would use this instead of Jackson. I guess x-platform is a big plus, but I'm currently using Kotlin exclusively on the server (i.e. JVM).