Licensing compatible with Meteor?

[dandv]

Since the Meteor community is well aware of the pitfalls inherent in Mongo, there was significant enthusiasm when we learned about Hyperdex.

However, from what I've seen in terms of licensing, it seems we might have a problem with going ahead and figuring out how to add support for HyperDex to Meteor.

Any ideas on how Meteor might still be able to use HyperDex?

CC @awatson1978

[rescrv]

Hi Dan,

Our license is located here: https://github.com/rescrv/HyperDex/blob/master/LICENSE.

This license covers the code that supports all the consistency, fault-tolerance, and atomic operations HyperDex is known for. Redis, MongoDB, and others stop at this feature set. We've gone further with HyperDex Warp, which adds ACID transactions across multiple keys on top. Although this is indeed our key feature, we could not make these guarantees to applications without the underlying HyperDex storage system.

From what I can see of Meteor, it'd do just fine with the fully-supported open source code base if the Meteor community's enthusiasm is deflated by the transactional add-on.

[awatson1978]

Hi Dan; Hi Robert;

The architecture behind Meteor relies on two packages called mongo-livequery and minimongo which basically implement a client-side replica-set. The good folks at the Meteor Development Group have effectively open-sourced the pattern for implementing client-side replica sets within web browsers; but even open-sourced, it's still a rather significant bit of database technology.

Porting HyperDex to Meteor in the way that people are wanting would basically involve writing a client-side replica set for HyperDex. But it's a tough sell to put the time and effort into implementing a hyperdex-livequery and minihyperdex package without the ACID transactions. The latency compensation depends on isomorphic APIs, and without the entire API available it just wouldn't make sense to try to do it at the community level.

This is something that either the HyperDex team would need to decide they want to implement themselves, or MDG would need to decide they want to approach HyperDex to purchase some type of global license (basically buy the tech from Cornell in some form). Both of which are beyond my ability to address. I'm not going to be sort through this.

Thanks for pinging me Dan. Robert, nice to meet you. For what it's worth, there's people in the Meteor community clamoring for your technology. You might have a market there if you can implement a hyperdex-livequery and minihyperdex package.

Best.

[rescrv]

I'm closing this issue because it sounds like the livequery and mini packages are a different design from Warp's transactions, and would likely require reworking both meteor and HyperDex. Implementing both on HyperDex remains possible.