boodebr.ion is designed to be a middle-ground between simple JSON serialization (which doesn't preserve full class information) and the "industrial strength" {{tt{xml.pickle}}} (which is overkill for many applications). The comparison chart below highlights the key differences.

Topic	pickle	JSON	boodebr.ion	xml.pickle
True object pickling? 1	YES	NO	YES	YES
Strict typing? 2	YES	NO	NO	YES
Maintains referential integrity? 3	YES	NO	NO	YES
Dictionary keys can be arbitrary objects?	YES	NO	NO	YES
Human-readable format?	NO	YES	YES	YES
Output formats	Proprietary	JSON	JSON, XML	XML
Handles arbitrary binary data? 4	YES	NO	YES	YES
Fine-grained control of pickling process? 5	NO	MAYBE	YES	YES

Footnotes:

1. The only data structures RFC 4627 recognizes natively are dictionaries and lists. All other types have to be converted to one of these types. boodebr.ion provides a layer on top of RFC 4627 to allow full pickling (while remaining 100% compatible with JSON).
2. Due to the limitations of RFC 4627, JSON and boodebr.ion will convert tuple->list and string->unicode. All data is preserved, but the exact type may change.
3. Preserving references (espcially self-referencing data) while allowing user-defined hooks is quite difficult. Dropping this requirement allows boodebr.ion to have a much simpler design than xml.pickle. If you need this capability, use xml.pickle instead.
4. Neither JSON nor XML are binary-clean formats. boodebr.ion and xml.pickle transparently encode/decode binary data so you never have to worry about it.
5. Depending on the JSON library you use, it may allow more fine-grained control. Both boodebr.ion and xml.pickle have a hook/plugin system for fine-grained control, although xml.pickle has a more extensive (and complicated) system.
   
   
   blog comments powered by Disqus