On Mon, Jun 29, 2009 at 11:03 PM, Benjamin M. Schwartz<bmsch...@fas.harvard.edu> wrote: > Eben Eliason wrote: >> On Mon, Jun 29, 2009 at 10:34 PM, Benjamin M. >> Schwartz<bmsch...@fas.harvard.edu> wrote: >>> Eben Eliason wrote: >>>> I know GroupThink does everything it can to prevent collisions, but >>>> with this we should also be thinking about the worst case. The >>>> intended baseline behavior (before we get into any fancy merging >>>> libraries) was to allow two instances with the same activity_id but >>>> different version_ids to run simultaneously, and be joined by any of >>>> their participants, thus allowing manual copy/paste merging. The >>>> instance left open last would then become, naturally, the most recent >>>> and therefore the "agreed upon" version moving forward. >>> Hmm. This creates a bit of a dilemma. >>> >>> In Groupthink, there is no such thing as a collision. You could say >>> "collisions are not supported". Therefore, my model has been that >>> different versions of a document should always be launched into a single >>> shared session, where the data will be merged immediately and >>> automatically. If the user wishes to create a separate branch not to be >>> automatically merged with the existing document, she should create a copy >>> of the journal entry with a new activity_id. (No, we don't seem to have a >>> UI for that.) >> >> The most basic UI for that, as I see it, is a "Keep a copy" secondary >> item under the Keep button. > > Yep. This is what I expected the "Copy" option in the Journal to do, but > that copies to the clipboard. Two options, "Copy to Clipboard" and "Copy > this Entry" would be necessary > >> >>> If the system is designed to prevent different versions from joining into >>> a single shared session, then perhaps this explains the observed behavior. >>> It also entirely prevents automerging of offline work. >> >> I don't think they're incompatible at all. > > I think we agree that they are incompatible as currently implemented, and > that any implementation that permits this sort of automerging looks > substantially different from what we have now, as you detail.
Yup. >> Hence, perhaps some need for asking an open activity instance if it >> can successfully "merge" (whatever that means to the activity) some >> other object handle its given. If success is returned, the merge >> happens; if failure is returned, the shell opens the requested >> activity normally. > > I do not think an "object-based" merge system is best for this purpose. > It seems to me that such a system would prevent any online "negotiation" > between the two sides. Things get dramatically uglier if you consider > joining a session containing many members, but not the initiator. Which > user gets to decide whether the new one can join, when all users are equal? The leaderless merge issue doesn't seem any harder than the basic leaderless collaboration issue. But I might be missing some obvious complications. The short of it seems to be that the activity would have to elect a given client to handle the merge. > It's not exactly a beautiful solution, but I'd prefer a toggle in > activity.info: automerge=True/False. If automerge is False or > unspecified, then we retain the current behavior (for the sake of And because the current behavior is the "correct" thing to do if merge can't be automatic anyway! > compatibility). If automerge is True, then different versions are always > combined into a single shared session. I'd carefully word this as "always attempted to be combined"... > To support "unreliable merge", we can use a self.unshare() method. If the > local activity process, after negotiating with other group members, > decides that merge is impossible, then it may leave the shared session > shortly after joining and return to private scope. > > How does that sound? This sounds almost exactly like what I was suggesting, but in the opposite direction. I was proposing to ask the activity on the fly if it could perform a merge (this method would return false if unimplemented), returning false when it wasn't possible (after whatever negotiation was necessary...this method could be async). You're suggesting to first check a global constant defined by the activity to see if it will even try to merge at all, and a second fallback method to be called (by the activity) in the case of a failure. Actually, I guess if it's async, our two methods are basically the same, except that you suggest the addition of the flag in .info, which seems like a reasonable enough idea, though not strictly necessary. In any case, both seem roughly equivalent in terms of experience, in which case I don't really care. =) Eben > --Ben > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel