0

I have some javascript objects that I'd like to collaboratively manipulate, but am having a hard time understanding the best way to achieve this in Meteor. These objects are NOT bound to specific collections, but rather live in-memory alongside the Templates that serve GUIs that are bound to collections.

I figured two things:

(1) Perhaps I should circumvent Meteor's native pub/sub stuff for this and simply leverage the existing SockJS infrastructure inside Meteor. I was able to get the SockJS URL from Meteor, but haven't successfully made a SockJS call yet. (I can provide more detail if need be)

(2) Or maybe leverage the existing pub/sub options in Meteor and use a Template as a shim to listen for updating. I looked here for that, but so far, haven't been able to iron out the kinks. Perhaps I should use a collection as a shim as well?

Again, these are NOT bound to collections, and I'd suspect vanilla SockJS or socket.io to be fairly straightforward on how to broadcast the changes. So, I'm struggling on how to incorporate collaboration in a Meteor app that doesn't originate with a collection being updated. I want to pursue one of the above, but would like to know which approach seems most feasible? Thanks for your help.

Community
  • 1
  • 1
TimDog
  • 8,758
  • 5
  • 41
  • 50
  • When you say 'are not bound to collections' what does that mean exactly? You don't want to persist the data? – Tom Coleman Aug 20 '12 at 10:35
  • It's mostly navigational -- users will be moving around in a given app and the data (navigation coordinates, etc) doesn't need persistence as it's a one-off experience. But I think there are number of scenarios outside navigation that warrant a means of collaborative manipulation without needing to be bound to a specific collection. – TimDog Aug 20 '12 at 13:07

2 Answers2

0

I guess there are two scenarios:

  1. Things that need to be collaborated on I think should be persisted in a collection. However if there is a large amount of such data that is very transient and it really doesn't make sense to use a collection, it is theoretically possible to wire up a collection which uses minimongo (in memory mongo) on the server side rather than the real mongo driver.

    The devs have indicated that it probably can be done, but AFAIK no one has actually gone ahead and tried it.

  2. Things that don't need to be collaborated on should just be stored in the Session client side I think.

Community
  • 1
  • 1
Tom Coleman
  • 3,037
  • 18
  • 16
0

I ended up using the new constant block helper that was released with Meteor 0.4.0 to keep my out-of-Meteor-scope javascript objects from being manipulated by Meteor:

http://meteor.com/blog/2012/08/31/introducing-spark-a-new-live-page-update-engine

This lets me update these objects via a different means than Meteor.

TimDog
  • 8,758
  • 5
  • 41
  • 50