Dependencies on Meteor implementation details
zs-zs opened this issue · 7 comments
Hi!
I see you don't plan to maintain this anymore so I'm thinking about to take over this, because it looks very promising. I took a quick look on your code and I see that you were using some Meteor internals which have changed since you implemented this package.
For example, you depend on Livedata in versioned-collection.js, but the _LivedataSubscription (or the corresponding Subscription) function is now private.
What do you think, do your code depend on internal behaviour so deeply or is it possible to rewrite that to make it work under the latest Meteor?
Hi! Unfortunately I cannot tell you whether recent changes in Meteor make a big difference. I've not been working with new versions of Meteor. There are some pretty strong dependencies on Meteor internals, though. Nevertheless I think the real value of this versioning tool is not in its connection to Meteor but in its version dependency discovery approach, so I think that you could re-use quite a bit of code even if the internals of Meteor changed completely. Of course I'm happy to let you take over. Feel free to fork and do whatever you like with the code. :-) Not sure how I could hand over the package on atmosphere so that you can reuse the same name. Maybe you want to find out?
Okay I will check your code when I have time. At the first sight it seems to me that the package relies on the Livedata feature that enabled you to subscribe Collection change events from all the Collections used by the hosting Meteor application. I think I can substitute this part with introducing a manual config step to the package API (using the cursor observe* methods)
Nice. :-) I'd be very happy to see this package live on.
Hi!
I started to read through your code.
With some hacking I was able to make it work again with the latest Meteor :-) I tested for your two sample codes and I also created a test UI where you can add a Todo item by hand and undo it and you can observe the replicated Todo items in a list.
However, in order to make it work, I had to publish the _todosCrdts collection somehow, so I removed the _preventAutoPublish flag from the Crdt collection, and it started to work.
But I don't really understand why did you do this: first, you prevent the publishing of the Crdt collection by setting the _preventAutoPublish flag, and later in the versioned-collection.coffee you are extending the _LivedataSubscription (which is not available in the latest Meteor anymore) to publish the crdt's changes manually. It seems like some workaround for some problem. Do you remember why did you need this?
It's also not very clear to me, why do we have to depend on the crdt collection changes on the client, because the UI elements and stuff on the client are binded to the snapshot collection - or am I missing something?
And a last question is that have you ever experienced any performance problems when creating lots of updates for a single "entity"? Or you didn't test it with long histories...?
As I understood, it seems that we have exactly one Crdt in the Crdt collection for every single snapshot in the versioned-table snapshot collection which stores the change history for that single snapshot. Is it correct?
Now when we commit a transaction, we update the Crdt, and then regenerate the snapshot from scratch. You go through every field's every change (this is what getOrderedVisiblePayloads do) and finally you store the snapshot in the snapshot collection.
It seems that as the size of your Crdts grow with every change, you will have slower and slower commits. Maybe it would be a better idea to generate the snapshots with a delta? This means you would go through only the delta changes, and apply it to the last snapshot.
What do you think?
Hi! Sounds like you make great progress. :-) Give me a few days to respond, ok? It's a long time since I hacked on that code and I have to wrap my head around it to answer your questions. Is there a way we could chat directly (Jabber, IRC, Skype, whatever you prefer)?
Hi! I sent you an email.
Hi!
For anyone who is interested - I will close this issue now, since I would like to take over the package, I've already forked it, and I've started to apply some changes. It should work with the latest Meteor now.