It would be even more awesome if this supported automatic data caching from subscriptions, like the Meteor web client with Minimongo or meteor-iOS does with CoreData: https://github.com/martijnwalraven/meteor-ios
Thanks! I've thought about this already but wasn't sure what to do.
In its original JavaScript implementation, Meteor has Minimongo, as you said. But building such an interface in Java would lose all the convenience, wouldn't it? The advantage of Minimongo is that you can use it just like MongoDB itself, e.g. "myColl.find({ _id: "some-key" })", which is not possible (with that syntax) in Java.
Then you mention Core Data from iOS, which is great as well, but specific to the platform again. Android doesn't have this.
What would be an equivalently widespread (and convenient) solution for Android? Storing it in SQLite? Or deeply nested "Map" instances?
The way I understand it, a replacement for Minimongo just for reading data needs two things:
1. A simple filtering/querying API (doesn't need to be as fancy as Mongo)
2. Change events on filtered views of data so that you can update the view
when new data comes from a subscription
1. Tracking of temporary changes from a specific method
2. Ability to roll back those changes when DDP tells you it's done
Such an in-memory database seems quite important for productivity, so I will definitely consider this.
Read access could be implemented in a first step, while the semantics would still have to be discussed. I think write access would actually be quite important as well so that you can completely abstract away the sending, receiving and processing of events.
Latency compensation or optimistic UI would be nice to have (for making applications more snappy), but I think this is only the third most important piece.
Maybe one can use "SQLiteOpenHelper" with "name" set to "null" for in-memory storage. Or perhaps some things can be adopted from or based on Minimongo, Realm or MapDB:
http://www.quora.com/How-is-Meteors-client-side-database-imp...