Depend on the BSON module on CPAN

[xdg]

The plan for BSON support in the official MongoDB driver is evolving as follows:

• BSON v1.0.0 (coming in the next month or so) will provide a complete, well-tested pure-Perl BSON encoder/decoder (BSON::PP) and a full set of BSON type wrapper classes
• BSON-XS v1.0.0 (coming in the next couple months) will provide a high-performance BSON encoder/decoder (BSON::XS)
• BSON v1.0.0 will use BSON::XS if installed or else fall back to BSON::PP
• MongoDB v1.6.0 (coming Q3 2016) will depend on BSON-v1.0.0 in order to provide Decimal128 support, but will still bundle its own XS-based encoder
• MongoDB v2.0.0 (coming Q4 2016 or early 2017) will remove its bundled encoder and depend solely on the BSON distribution (and thus automatically get either BSON::XS or BSON::PP); legacy MongoDB namespaced type wrappers (e.g. MongoDB::Code) will become empty subclasses of BSON namespaced type wrappers (e.g. BSON::Code).

If Mango were able to make a similar change -- depending on BSON and using (subclassing) its type wrappers, then Mango wouldn't have to support BSON changes over time and could offer both a pure-Perl or XS backend without any extra development.

This might involve some breaking changes or work to ensure compatibility in the type-wrappers, but might be worth it in the long run for Mango users. I'm happy to help think through implications and approaches.

[oliwer]

Thanks a lot for all the info. I also think this is the way to go. My new job is stealing a lot of my time but I will email you later to talk about BSON::PP in more details.

[alexbyk]

+1

[oliwer]

I see this migration happening in 2 steps:

1. Mango 1.30 will change its API to be compatible with the official BSON API. This is what I started to do in the bsonapi branch (commit). While this does introduce many changes, most of them are trivial and this is the only way to stay clean and not have users use both BSON and Mango::BSON in their applications.
2. Mango 2.00 will completely remove Mango::BSON and its subclasses. I might leave Mango::BSON.pm temporarily just as an alias of BSON::Types.

The 2 major breaking changes i can see are:

• BSON::Time and Mango::BSON::Time are very different
• BSON::OID misses a from_epoch constructor. But maybe we could add it? It seems we are the only driver providing this feature though.

[xdg]

A while ago, I reviewed all the various BSON modules to compare APIs/implementations (as of BSON 0.16). You might want to review that in case I missed something: https://github.com/mongodb/mongo-perl-bson/blob/master/devel/bson-types-survey.md

Note: the final implementation in BSON.pm has likely diverged from this comparison, but it's a good reference.

Re Mango::BSON::Time, most of the functionality is there, but the APIs are different. One possibility might be to continue to provide it as a subclass of BSON::Time that preserves the legacy API. Getting Mango::BSON::Time objects in/out might require implementing conversion hooks, for which I have a draft design here: https://github.com/mongodb/mongo-perl-bson/blob/master/devel/typemap.md

[kraih]

I'm not actually using Mango anymore, but given the history of this module, i think it should stay as independent as possible from MongoDB Inc.