Is there a formal mechanism for cleaning up when no active connection (i.e. opening) to a collaborative object?

[ngwaitat]

Is there a formal mechanism for cleaning up when no active connection (i.e. opening) to a collaborative object?

[pablojan]

No, there is no formal thing to do this. But it is an interesting question. Is this clean up absolutely necessary in a collaborative context? I would like to know better your needs if you don't mind in order to give a better answer. A private area in the object for each participant would be good for your scenario? 2017-11-29 10:34 GMT+01:00 ngwaitat <[email protected]>:

…

I want to clean up the collaborative object (like destroy some of its data) when all opening of the object has been closed, but I have difficulty achieving this. My first plan is to increment a count as a property on the object, then decrement the count when the web application closed. But since the app will prompt user to save modified data so I cannot do the decrement count in window.onbeforeunload (because user may choose to stay) and I must do in window.onunload instead. This caused a problem because I found in window.onunload, I cannot modify the collaborative object's property in Firefox (reload the page the count will be old), Chrome would be ok if I update the count once, but the 2nd updates onward will again fail. So I would like to know is there a formal way to handle situation like mine? Thank you very much! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/P2Pvalue/swellrt/issues/228>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEP6D5w8DE3RkgJCdxMFfRxDKwQ7jeKXks5s7SUXgaJpZM4QuqXT> .

[ngwaitat]

Yes, the clean up has to rely on the collaborative context instead of just a private area. My scenario is as follow:

1. There are two editors, when startup each editor will load its data from the previously auto saved medium (file/database).

2. After loaded the saved data, each editor then open the collaborative object so that both real time state are synchronized initially.

   2.1. When the first editor open the collaborative object, it finds that it is new. It then initialize the collaborative object with the data it loaded.

   2.2. When the second editor open the collaborative object, it isn't new so it has to refresh its own data from the collaborative object instead.

3. In my ideal case, when both editors finished with the collaborative object, the last editor realized it is the last user, then it either delete the collaborative object (seems currently no this option), or mark it as invalid, so the next user will initialize like step 2.1 does.

I'm not sure how JetPad is implemented, maybe it has no this problem because the collaborative object is used as the data storage medium as well. So there is no separating between the two. But if I were to separate data storage and real time object when no clean up is available, then in step 2.1 I'll have to load from the previously saved collaborative object again, which is unnecessary because it would be the same as the last auto-saved data. This is the reason why I would prefer a clean up mechanism.

[pablojan]

It seems your scenario is not usual for Swell's design. As you rightly have guessed, JetPad uses Swell as storage. That is the main feature of Swell indeed. In your case, I don't see clear whether each client has its own local storage (file). Anyway, the point is, in systems like Swell (with central real-time concurrency control that is eventually consistent), it doesn't make sense to try to manually sync things in a decentralized way. None options will be perfect. One option could be to sync that local storage directly with the Swell server, using a kind of robot (through the Java client for example). Then avoid each client to handle sync. At this moment, Swell objects are always persistent and cannot be deleted, but I am working on volatile objects (those which only exists in memory of the server) and hard/soft deletion of objects. 2017-12-04 16:20 GMT+01:00 ngwaitat <[email protected]>:

…

Yes, the clean up has to rely on the collaborative context instead of just a private area. My scenario is as follow: 1. There are two editors, when startup each editor will load its data from the previously auto saved medium (file/database). 2. After loaded the saved data, each editor then open the collaborative object so that both real time state are synchronized initially. 2.1. When the first editor open the collaborative object, it finds that it is new. It then initialize the collaborative object with the data it loaded. 2.2. When the second editor open the collaborative object, it isn't new so it has to refresh its own data from the collaborative object instead. 3. In my ideal case, when both editors finished with the collaborative object, the last editor realized it is the last user, then it either delete the collaborative object (seems currently no this option), or mark it as invalid, so the next user will initialize like step 2.1 does. I'm not sure how JetPad is implemented, maybe it has no this problem because the collaborative object is used as the data storage medium as well. So there is no separating between the two. But if I were to separate data storage and real time object when no clean up is available, then in step 2.1 I'll have to load from the previously saved collaborative object again, which is unnecessary because it would be the same as the last auto-saved data. This is the reason why I would prefer a clean up mechanism. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/P2Pvalue/swellrt/issues/228#issuecomment-348993186>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEP6D6tXWRjgPRSbzs4qnilAwYDAjM8Fks5s9A2lgaJpZM4QuqXT> .

[ngwaitat]

No problem. Thank you very much :)