browser compatible

[aheckmann]

[tarqd]

To make this easier, I think the actual querying should be left out of this repo (remove the mongodb dependency) and allow passing any object that implements the collection interface or even just having this library simply generate valid query objects. For example I have my own fork that returns an object with the final query/updateDoc/options, which I then pass to a component that converts simple queries to RESTful urls to use client-side

[aheckmann]

sounds good to me

[tarqd]

Do you think it'd be better to return a query object or just have it so you pass a collection object to the library?

[aheckmann]

that's actually how it works today. we just wrap the passed collection in a compatibility layer. We should break the layer out and define it so its easy to create other compat layers.

[aheckmann]

so you need access to the fields/options etc? we could expose that.

[aheckmann]

Right now if you override mquery.Collection we'll use that instead but it must conform to the mquery collection API. take a look at lib/collection

[tarqd]

Only problem with a browser version is lib/utils.js currently requires mongodb (for ReadPref and ObjectId). I'd say have the collection define it (NodeCollection.ObjectId or NodeCollection.Types.ObjectId)

That way you can just define polyfills for those types for the browser/mongoshell

[aheckmann]

that sounds good for now. maybe nice to provide a clean env abstraction which provides the collection,objectid,readpref etc.