Re: Mini-Conference Proposal: Frameworks for Collaboration
On Sat, Mar 29, 2008 at 1:47 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: We will have an open discussion of how to build a framework that will ease the creation of reliable collaborative activities. I will also outline a proposal for Collisionless, a particular message-based API that encompasses both real-time and offline collaboration. The key idea of Collisionless is to break down high-level tasks into a sequence of messages whose significance does not depend on the order in which they are received. Hmm. I've always thought of a high-level framework here as based on a shared undo/redo list, since most mature applications support undo/redo. The idea is that we provide the necessary distributed consensus algorithms to allow all participants to agree on the order of the entries in their undo/redo list; anyone who had actions applied in the wrong order performs undos, then redos to adjust their order. When you present your proposal, I'd love to hear a comparison to this approach. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mini-Conference Proposal: Frameworks for Collaboration
C. Scott Ananian wrote: | On Sat, Mar 29, 2008 at 1:47 AM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | We will have an open discussion of how to build a framework that will ease the | creation of reliable collaborative activities. I will also outline a proposal | for Collisionless, a particular message-based API that encompasses both | real-time and offline collaboration. The key idea of Collisionless is to break | down high-level tasks into a sequence of messages whose significance does not | depend on the order in which they are received. | | Hmm. I've always thought of a high-level framework here as based on a | shared undo/redo list, since most mature applications support | undo/redo. The idea is that we provide the necessary distributed | consensus algorithms to allow all participants to agree on the order | of the entries in their undo/redo list; anyone who had actions applied | in the wrong order performs undos, then redos to adjust their order. | When you present your proposal, I'd love to hear a comparison to this | approach. That is a very interesting perspective. I will definitely think hard about that and try to come up with a sensible comparison. Offhand, I think the Collisionless idea is like a design where each person's Undo/Redo list can be in a different order, and yet always reach the same final state, as long as they contain the same total set of edits. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mini-Conference Proposal: Frameworks for Collaboration
On Sat, Mar 29, 2008 at 3:05 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: That is a very interesting perspective. I will definitely think hard about that and try to come up with a sensible comparison. Offhand, I think the Collisionless idea is like a design where each person's Undo/Redo list can be in a different order, and yet always reach the same final state, as long as they contain the same total set of edits. Yes, just to be clear, I'm very interested in hearing your proposal in full. It just seems to me that the primary objection would be of the form, but real applications don't have collisionless actions and so I thought I'd give you a chance to rebut that point in your presentation. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mini-Conference Proposal: Frameworks for Collaboration
On Sat, Mar 29, 2008 at 1:05 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: C. Scott Ananian wrote: | On Sat, Mar 29, 2008 at 1:47 AM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | We will have an open discussion of how to build a framework that will ease the | creation of reliable collaborative activities. I will also outline a proposal | for Collisionless, a particular message-based API that encompasses both | real-time and offline collaboration. The key idea of Collisionless is to break | down high-level tasks into a sequence of messages whose significance does not | depend on the order in which they are received. | | Hmm. I've always thought of a high-level framework here as based on a | shared undo/redo list, since most mature applications support | undo/redo. The idea is that we provide the necessary distributed | consensus algorithms to allow all participants to agree on the order | of the entries in their undo/redo list; anyone who had actions applied | in the wrong order performs undos, then redos to adjust their order. | When you present your proposal, I'd love to hear a comparison to this | approach. That is a very interesting perspective. I will definitely think hard about that and try to come up with a sensible comparison. Offhand, I think the Collisionless idea is like a design where each person's Undo/Redo list can be in a different order, and yet always reach the same final state, as long as they contain the same total set of edits. --Ben On any data structure with internal order (ie, anything much more complex than a set), it is impossible to have an arbitrary set of edits result in the same final state independently of order. Obviously, from both the name collisionless and from this logic, you must add constraints: a given set of edits is collisionless if you can apply them in any order; in the example of a text file, collisionless essentially means that they edit different portions of a file. When there is a dispute about the order of collisionfull edits, some explicit merge algorithm is needed - either one edit wins and the other loses, or you arbitrarily assume an order, or you ask for user intervention. I would simply pose the case of source control - the one I'm interested in for Develop. Even if two people edit entirely different files, it is not 100% safe to have an automatic merge of their code - say both fixed the same bug by incrementing the same variable, but now it gets incremented twice. Honestly, in a loose kind of environment, as most XO coding will be, fine, we'll catch that in testing is an OK answer to that, especially if you have automatic tests. But in order to debug that once you catch it, you need tools for seeing who did what when, ones which highlight any automatic merges as possible sources of problems. I know, source control is a special case, and you don't want to contort your framework for this special case. My main point here is that the framework will be most useful if: - it allows its client app to decide what to do in the case of collisions - it notifies the client app even of crossovers that aren't collisions - it provides some support for keeping track of who did what, even when there aren't crossovers or collisions In other words, do your magic, please, but tell me about it if I care. It is easy to think of non-source-control use cases for all of the three cases above. This is not to say that a totally black-box solution wouldn't be useful for many, just that a more open solution would be more so for more. Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Mini-Conference Proposal: Frameworks for Collaboration
Title: Frameworks for simultaneous and sequential collaboration Abstract: The OLPC sharing design encompasses two rough classes of sharing. In the simultaneous case, a number of students join a shared Activity and all edit a document together in real time. In the sequential case, students make local copies of a document, edit it by themselves, and then post the result for others to continue editing. Current implementations of simultaneous collaboration have largely used ad-hoc messaging protocols over Telepathy. Sequential collaboration has not yet been implemented, but many have viewed it from the perspective of Version Control Systems, with the accompanying branch and merge metaphors. We will have an open discussion of how to build a framework that will ease the creation of reliable collaborative activities. I will also outline a proposal for Collisionless, a particular message-based API that encompasses both real-time and offline collaboration. The key idea of Collisionless is to break down high-level tasks into a sequence of messages whose significance does not depend on the order in which they are received. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
